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Les systemes d'information sont directement visibles chez les 
clients finaux. C'est pourquoi il est crucial de maitriser la resolution 
des problemes sur la qualite des services pour toutes les DSI. En 
effet, plusieurs phenomenes se sont produits : 

- Les systemes sont devenus de plus en plus complexes, 
distribues et transverses, et mettent en oeuvre plusieurs 
technologies en simultane. 

- Les exigences des clients internes vont croissant. 

- Les regimentations legates pesent lourd sur les DSL 

- Les delais alloues pour les developpements sont 
contraignants. C'est le prix a payer pour rester dans la 
course de la competitivite. 

Par ailleurs, le marche de I’Europe, ainsi que celui de I'international, 
ouvre une nouvelle concurrence vis-ei-vis de laquelle etre 
competitif devient vital pour les entreprises. Confrontees a des 
defis toujours plus complexes et repetitifs, il est certain qu'avoir 
les bonnes methodes d'analyse des problemes et de prise de 
decision soit un sujet de tous les instants pour un developpement 
durable de leur qualite de service. 
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PREFACE 


Longtemps dans la gestion de services aux clients, et dans la gestion 
de la production qui en decoulait, etaient pris en compte exclusive- 
ment la gestion des incidents et son lot d’indicateurs associes 
(nombre, delais de remise en service, delai de resolution, etc.). Ce 
premier pas pouvait suffire, excepte dans des situations critiques : 
quelle confiance auriez-vous dans les trains si le service de mainte- 
nance changeait plus de mille fois une partie des rails tous les mois ? 
Les systemes de plus en plus complexes, les besoins constants 
d’amelioration des engagements de service en parallele de la baisse 
des couts, les evolutions a marche forcee, la necessite du « temps 
reel » se traduisent par des services disponibles 24 heures sur 24 et 
7 jours sur 7, et ou chaque interruption entraine du mecontentement 
et parfois la perte du client qui est dans certains domaines tres volatil. 
Parmi 160 000 incidents par mois, lesquels sont prioritaires ? Quelle 
organisation mettre en place ? Comment effectuer un suivi correct 
des contrats de niveau de service (Service Level Agreement ou SLA) 
pour satisfaire ses clients ? Dans ce flux permanent, comment distin- 
guer les sujets de fonds, les causes reelles et les vrais problemes ? Et 
s’il n’y a plus que 50 000, 20 000 ou 600 incidents par mois, l’appro- 
che est-elle la meme ? Quel est l’effort a mettre en place ? Comment 
gerer les variations ? Comment assouplir un dispositif ? 

Devant ces enjeux vitaux pour les entreprises, la gestion des inci- 
dents n’etait pas suffisante. L’analyse de fond permettant de suppri- 
mer definitivement les incidents pour arriver a la notion de « zero 
interruption de service (zero outage) », chere a de nombreuses gran- 
des SSII, s’est appuyee sur la gestion des problemes. Apres une 
premiere etape manuelle, la gestion des problemes ou GDP s’est 
renforcee ces dernieres annees par des outils d’identification par 
correlation plus complexes et plus fins dans l’analyse. 
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Mais en complement, il est necessaire de mettre en place les modali- 
tes et procedures adequates pour assurer que 1 500 changements ne 
vont pas induire une seule rupture de service dans le mois. Quelle 
credibility peut-on accorder a des systemes de preproduction qui 
sont parallelises a l’extreme ? Comment s’assurer que tous les tests 
sont effectues et sont concluants ? 

Sur des equipes de production depassant 200 personnes, quelles 
metriques adopter pour avoir confiance dans son dispositif et en ses 
equipes ? Comment organiser sa flexibility, son turn-over et sa part 
de sous-traitance ? Comment etre certain que le dispositif reste dans 
la logique de couts mise en place ? Comment integrer les efforts 
financiers demandes sans destabiliser l’ensemble ? 

ITIL n’est pas une baguette magique ! Non, l’objet est plus d’amener 
un langage, du bon sens et de la rigueur dans un contexte ou Ton est 
generalement deborde par les contraintes et les plannings. Cette 
approche laisse une tres large place a l’ingeniosite et a l’experience 
des equipes. Dans ce cadre, on passe du stade du concept a celui de 
la realisation : on se base sur l’experience et les resultats obtenus sur 
le terrain. Ces derniers seront une source d’enseignement riche et 
pragmatique. 


Jean-Marc Bellet 
Directeur du developpement des comptes 
et des Regions d’EDS France 
Membre du comite executif d’EDS France 
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Marc Lamy 
Directeur general d’EDS Maroc 
Membre du comite executif d’EDS France 



AVANT-PROPOS 


A l’ere de la mondialisation et d’une competitivite toujours plus 
accrue, la recherche de la productivity et de l’efficacite est devenue 
un point de passage oblige pour la profitability et l’image de marque 
des entreprises. Si le monde industriel en avait deja conscience 
depuis de nombreuses annees, le monde informatique, apres un 
essor fulgurant dans les annees 2000, notamment en Europe, se mue 
a son tour progressivement, mais avec rythme, vers l’objectif d’une 
meilleure qualite de service au meilleur cout. 

Evidemment, l’objectif supreme est de s’agrandir en veillant a 
toujours rester centre sur son coeur d’activite pour delivrer le meilleur 
service possible. Pour cela, les efforts des organisations et de leurs 
dirigeants se portent sur le developpement de nouvelles structures, 
de nouveaux outils tant sur un plan technique que methodique. Para- 
doxalement, le developpement du systeme d’information entraine 
egalement une complexity croissante des problemes sur la qualite de 
service. Jusqu’alors, nous n’avions jamais eu l’occasion d’apprehen- 
der l’information en temps reel. Le laps de temps qui nous etait 
necessaire pour verifier l’information, controler les donnees et filtrer 
le contenu est aujourd’hui tres reduit. II est devenu tout simplement 
vital de se doter d’une reelle capacite de gestion de tous les flux pour 
acheminer la bonne information au bon moment, au bon endroit, et 
cette reactivite est un gisement de qualite pour le service attendu par 
le client : la maitrise de l’information est la cle du futur. 

C’est sans surprise qu’il devient done indispensable d’adopter dans 
les organisations la methode de resolution des problemes qui vien- 
nent entraver la maitrise de cette information. 

Les metiers de support et de soutien au service connaissent un 
renouveau. Une nouvelle fagon d’exploiter le systeme d’information 
s’annonce pour les annees a venir. 11 ne s’agit plus simplement d’effi- 
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cache, de reactivity, de service, mais plus que jamais de productivity, 
de proactivite et de qualite de service. 

Cet ouvrage, tire de mon experience de consultant en management 
des systemes d’information, a pour but de presenter de fagon prag- 
matique les moyens necessaries a la mise en oeuvre de la gestion des 
problemes pour l’amelioration de la qualite de service, selon le refe- 
rentiel des meilleures pratiques ITIL. 

En plus d’avoir le merite d’apporter des cles et des outils pour mieux 
nous permettre d’apprehender la gestion des problemes de qualite 
sur nos services, ces methodes doivent nous servir d’engrais pour 
faire germer les evolutions organisationnelles et socioculturelles 
necessaires a l’amelioration du service fourni, gage de reussite face 
aux defis d’aujourd’hui et de demain. 

Les problemes de qualite de service auxquels les Directions des 
Systemes d’information (DSI) doivent faire face n’ont rien de 
nouveau et font partie integrante du quotidien. Ils doivent done etre 
pris en compte dans le cadre d’une activity recurrente, malgre un 
contexte de tiraillement perpetuel entre : 

• La necessite de faire evoluer son systeme pour rester dans la 
course des enjeux technologiques de demain contre la necessity 
de stabiliser ce meme systeme afin d’augmenter la fiabilite des 
services fournis en continu aux clients. 

• La necessity d’etre aux avant-postes, d’etre reactif et innovant 
pour mieux anticiper les besoins des clients en developpant les 
offres de services adequates au bon prix, mais aussi au bon 
moment (avant les autres) contre la necessity d’effectuer tous les 
tests et controles necessaires qui doivent garantir une bonne 
exploitabilite du service. 

• La necessity de personnaliser son rapport avec la clientele, de 

segmenter son portefeuille de services pour asseoir la creation de 
valeur aupres de clients cibles, contre la necessity d’industrialiser 
et de rationaliser le plus possible au travers d’une demarche 
processus, au sein de son organisation, et ce afin de maitriser ses 
couts. 1 

C’est ainsi que nos problemes de tous les jours se sont bien evident- | 
ment complexifies au fur et a mesure que nos technologies se sont | 
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rendues tres disponibles, jusqu’a une accessibility 24 heures sur 24 et 
7 jours sur 7, ou mane jusqu’au haut debit. 

La resolution des problemes sur la qualite de services est un savoir 
qu’il est devenu crucial de detenir pour toutes les entreprises qui 
souhaitent elever et maintenir la satisfaction et l’enthousiasme chez le 
client, et ce de fagon durable. II s’agit d’un acte de management 
avant tout. 

Comme le Dr Charles Kepner et le Dr Benjamin Tregoe l’avaient 
observe, lorsque les officiers de l’US Air Force prenaient les bonnes 
decisions, ce n’etait pas tant grace a leurs grades ou a leurs parcours 
professionnels qu’au processus logique utilise, permettant de rassem- 
bler, d’organiser et d’analyser les informations avant d’agir. 

Dans cet ouvrage, nous tacherons done d’aborder une presentation 
du processus de gestion et de resolution des problemes de sorte que 
tout acteur puisse quotidiennement contribuer sur son perimetre a 
renforcer le maillage de son organisation qui porte l’enjeu de la 
qualite de service. 

Pour la mise en oeuvre et l’applicabilite de ce processus, nous abor- 
derons egalement : 

• les principes methodologiques et pratiques de resolution des 
problemes ; 

• les prerequis de fonctionnement et de gestion ; 

• les aspects organisationnels ; 

• la conduite du changement. 

Face a des defis toujours plus grands, maitriser la bonne methode 
d’analyse des problemes et de prise de decisions permet le develop- 
pement durable de la qualite de service necessaire dans tout secteur 
d’activite. 



INTRODUCTION 


CONTEXTE DANS L’ENTREPRISE 

Quand les dysfonctionnements qui viennent entraver la qualite de 
services surviennent les uns apres les autres, II est difficile de nier les 
degats, et mieux vaut vous en apercevoir avant vos clients. 

A peine un premier dysfonctionnement est-il resolu, qu’un autre se 
declare. Quand il ne s’agit pas d’un incident dont l’impact est 
extreme pour l’utilisateur, il s’agit de cet incident qui arrive fidele- 
ment tous les jours a la meme heure, le matin lorsque Ton a pris son 
cafe et que Ton s’apprete a commencer sa journee. 

Du cote de la Direction des Systemes d’Information, chacun deborde 
de bonne volonte et s’active pour regler les dysfonctionnements qui 
sont declares heure apres heure, minute apres minute, en tentant 
d’apporter aux utilisateurs des services informatiques et aux clients 
finaux de l’entreprise la solution de contournement la plus rapide 
possible. Mais les personnels sont en general debordes et cela se 
ressent sur la qualite de service : celle-ci se maintient avec de tres 
grandes difficultes a une valeur de 82,54 % du niveau convenu, 
malgre un investissement parfois surhumain. Que faudrait-il accom- 
plir de plus pour que cette qualite de service s’ameliore ? demandent 
les membres du comite de direction general en s’adressant a la Direc- 
tion des Systemes d’Information (DSI). 

On ne sait plus quoi inventer. Le sentiment d’avoir deja tout essaye 
regne dans le quotidien alors que les utilisateurs ne cessent de mani- 
fester leur mecontentement grandissant de jour en jour. 

I 

|_ L’incomprehension des deux mondes est en place : 

I « Ces utilisateurs, ces clients, ne sont-ils pas finalement devenus 

° excessifs ? Peut-etre meme l’ont-ils toujours ete ? » 



14 Ameliorer la qualite des services 


« Finalement, nous faisons tout notre possible, et rien ne peut etre 
parfait. . . C’est done certainement qu’ils exagerent. . . » 

« Que faire de plus pour les satisfaire ? » 

Dans le meme temps, la DSI passe de mauvais moments et fait face a 
des incidents dont le degre d’impact ressemble vraiment a un achar- 
nement du sort (ou de la loi de Murphy). Et un beau jour, l’enquete 
de satisfaction client laisse tout le monde bouche bee : un total ne 
depassant pas les 55 % de satisfaction client sur une population 
couvrant pres de 95 % des utilisateurs des services informatiques. 
Comment est-ce possible ? Que s’est-il passe ? Le resultat aussi 
mediocre est-il du au fait que c’est la premiere fois que l’enquete est 
realisee ? Le resultat correspond-il reellement a la perception des 
clients vis-a-vis des services rendus par l’informatique ? 

D’experience, la reponse a cette derniere question est « oui », mais il 
est dur de l’admettre du premier coup. . . 

« C’est a cause du Centre de services » disent certains ! 

« Si les incidents etaient mieux geres, les clients n’auraient pas 
exprime un tel taux d’insatisfaction. » 

« C’est a cause des experts, dit le Centre de services. S’ils nous repon- 
daient plus rapidement, les clients seraient plus satisfaits. » 

« C’est a cause des gestionnaires de niveaux de services, disent 
encore d’autres. Si nous ne nous etions pas engages a satisfaire des 
niveaux de services que nous sommes incapables de delivrer, nos 
clients n’auraient pas ete degus et ne nous jugeraient pas aussi mal. » 
Quoi qu’il en soit, c’est l’impasse. Au fond, tout le monde se sent 
coupable de quelque chose, tout le monde se sent responsable au 
regard de cette situation sans savoir reellement de quoi, ou pourquoi 
exactement. Et finalement, on pourrait presque aller jusqu’a s’en 
convaincre reellement : le veritable probleme, dans le fond, c’est lui, 
le client ! Il ne comprend rien a rien, il n’est pas a l’ecoute de nos 
contraintes, il semble vouloir ignorer toutes les difficultes que nous 
rencontrons pour exploiter le systeme. Si l’informatique tombe en 
panne parfois, que pouvons-nous y faire ? A part reparer, ce que j 
nous faisons deja tous les jours, nous ne pouvons pas grand-chose. |> 
Les clients nous demandent vraiment l’impossible. Ils veulent un | 
systeme qui marche tout le temps ! (Et puis quoi encore. . .) | 
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II faut leur expliquer la complexity du systeme que nous gerons, 
notre supervision et ses limites, notre automatisation des traitements 
informatiques et surtout le nombre incroyable de process qui 
s’executent en production ou encore combien il est devenu difficile 
de maitriser l’administration des nouvelles technologies... 

Cette situation peut aussi vous arriver (si ce n’est pas deja le cas...) : 
ce type de contexte est frequemment rencontre dans les entreprises, 
et fait le cauchemar de nombreuses Directions des Systemes d’lnfor- 
mation. 

Besoin d’alignement 

S’il est besoin de le preciser, l’amelioration de la qualite de service 
n’est pas l’affaire d’une seule personne ou meme celle d’une seule 
entite ou d’un seul service (qu’il s’agisse du Centre de services, 
d’experts ou d’autres encore). C’est un effort auquel participe toute 
une equipe et dont chacun des contributeurs porte une responsabi- 
lite sur un perimetre d’activite, pour un interet commun a tous : celui 
de l’entreprise. 

Alors effectivement, a voir les choses sous cet angle, on comprend 
vite qu’ameliorer la qualite de service est un objectif qui concerne 
beaucoup de monde dans l’entreprise, et qu’il est necessaire d’intro- 
duire le changement pas a pas et de fagon homogene. Pour cela, il 
est necessaire de se doter d’une direction globale et coherente, d’une 
ambition commune ou tout le monde puisse se reconnaitre, tous les 
jours dans son metier, son activite et sa mission. Il faut une veritable 
connexion aux services attendus par le client (pour la meilleure 
comme pour la pire des qualites de service). 

Les mots qualite et service doivent faire un tout dans l’esprit de 
chacun. Vu la forte contribution de l’informatique dans notre monde 
actuel, que ce soit dans le secteur de l’industrie, de la telecommuni- 
cation, des banques, de l’energie et d’autres encore, l’obsession de 
chaque membre de l’entreprise et a plus forte raison de la Direction 
„ des Systemes d’Information doit etre de satisfaire ses clients et de 
I rendre le meilleur des services au quotidien sur son perimetre. 

| La DSI doit mettre le client et la qualite de service au coeur de son 
| organisation. 
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Une fois qu’on a dit cela, on peut presque avoir envie de rentrer chez 
soi en ayant l’impression d’avoir deja fait quelque chose. Seulement 
la encore, nous ne sommes qu’au commencement d’une route jalon- 
nee de plusieurs etapes, dont la premiere sera sans nul doute d’effec- 
tuer une reelle introspection dans l’organisation : comment proceder 
pour placer, dans l’organisation, le client et la qualite de service au 
coeur des preoccupations de chaque collaborateur ? 

A cette question tout aussi simple que pertinente, on peut repondre 
qu’il s’agit d’un reel defi car cela signifie un plan de transformation 
que beaucoup sous-estiment. 

La mise en oeuvre d’une demarche qualite dans nos services se doit 
d’etre accompagnee d’une serieuse prise en compte de la culture de 
l’entreprise. C’est un facteur fondamental pour la reussite du change- 
ment. Au-dela des bonnes pratiques et des methodes, pour qu’un 
changement s’opere, il faut etre pret a le recevoir dans une situation 
qui demeure, avant toute chose, un contexte humain. 

Methodes et standard ITIL 

Sur le sujet des methodes et des bonnes pratiques, nous savons 
qu’ITIL (Information Technology Infrastructure Library) regorge 
d’idees et de principes pour permettre d’engager un tel plan de trans- 
formation de la qualite de service au travers de la mise en place de 
processus. Mais generalement, lorsque l’on fait connaissance avec 
ITIL, on met du temps a comprendre qu’ITIL n’est pas une cible a 
atteindre. 

Ce n’est pas d’une quete du Graal des certifications ITIL dont nos 
clients ont besoin pour etre enfin satisfaits de leur service. Alors que 
faire ? Comment le faire ? Quel processus mettre en place pour 
ameliorer le service rendu a nos clients ? Toute la difficulty de 
l’appropriation des bonnes pratiques ITIL reside dans la capacite 
d’une organisation a finalement s’approprier ce dont elle a reellement 
besoin ou non, pour s ’aligner avec son client et ce quelles que soient 
les pratiques ITIL qu’elle adopte ou pas. 

Une bonne question a se poser serait : comment la methode ITIL J 
peut-elle dans le cadre de mon contexte m’apporter les plus qui vont |> 
faire la difference sur mon service pour l’ameliorer en continu, et | 
encore mieux satisfaire mes clients ? ^ 
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Tout d’abord et avant d’elaborer une reponse sur ce registre, il faut 
savoir que s’interesser a l’amelioration de la qualite de service, c’est 
avant tout aligner sa vision : faire coi'ncider ses objectifs avec les 
enjeux de l’entreprise, sa strategic avec le besoin et les exigences des 
clients et surtout garder a l’esprit qu’ITIL n’est pas une finalite ni une 
solution : ITIL est un moyen. 

Voila de quoi rester pensif face a ces consultants chevronnes qui 
viendront vous parler d’lTIL comme s’ils vous vendaient la solution 
miracle a tous vos problemes. En definitif, faites attention a ne pas 
tomber dans la caricature qui consiste a adopter ITIL dans toutes les 
situations sans finalement avoir pose cette question cruciale du 
besoin et du but a atteindre. Et dans ces deux domaines, vous seul 
savez quel niveau vous avez l’ambition d’atteindre. 

Normalement, vous connaissez tout cela mieux que quiconque, ne 
serait-ce que pour avoir ecoute vos clients. Votre but n’est-il pas 
d’offrir a vos clients la meilleure qualite de service au meilleur cout et 
de fagon continue ? Alors ayez present a l’esprit que c’est aussi 
l’objectif de toutes les entreprises concurrentes. 

Approche orientee Services 

Une fois cette idee bien ancree qu’ITIL n’est pas une solution mais un 
moyen, et que le but est la qualite de service, il est temps de se poser 
les bonnes questions : ITIL est un moyen, mais pour quoi faire ? Pour 
faire de l’exploitation ? Bien sur que non, car le monde change. La 
croissante et quotidienne dependance des clients et utilisateurs vis-a- 
vis de la performance du systeme d’information est quand meme une 
revolution. 

Il y a une dizaine d’annees, l’informatique fonctionnait selon le mode 
pompier et la culture de l’exploit. Chacun a certainement vecu sa nuit 
blanche en production pour relancer coute que coute les lots ou 
batchs de facturation de ses clients ou deboguer un systeme comple- 
tement inoperant mettant au chomage technique tout un centre 
d’appels ! Seulement aujourd’hui, qui s’en vanterait ? 

| Que s’est-il passe ? Il ne s’agit pas d’une simple histoire de reduction 
J> de cout. La culture de l’exploit ne pouvait plus suffire a maintenir la 
I qualite de service pour la simple raison qu’il s’est passe plusieurs 
| phenomenes depuis ces dernieres annees : 
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• Nos systemes sont devenus de plus en plus complexes, de plus 
en plus distribues, de plus en plus transversaux et mettent en 
oeuvre plusieurs technologies en simultane. 

• Les exigences de nos clients internes sont, d’une annee sur 
l’autre, de plus en plus importantes. 

• Les reglementations legales pesent de plus en plus sur les DSI. 

• Les delais alloues pour les developpements sont contraignants. 
C’est le prix a payer pour rester dans la course de la competitivite. 

• Le marche de l’Europe, ainsi que celui de l’international ouvrent 
une nouvelle concurrence vis-a-vis de laquelle etre competitif 
devient vital. 

• Le travail en temps reel est en pleine expansion avec les services 
apportes par les technologies Internet. Nous sommes dans l’ere 
du « tout pour tout de suite » et de la dematerialisation, ce qui 
necessite des infrastructures a forte disponibilite. 

• Nos systemes d’information sont directement visibles chez nos 
clients finaux. 

Les entreprises ont besoin de passer de l’exploitation technique de 
batch (lot), de traitement, et de process a une reelle exploitation des 
services. Nous nous en etions apenjus, mais cette prise de conscience 
doit etre muee en une reelle capacite collective a agir en coherence 
avec ce nouveau monde : le client attend qu’on lui rende un service 
et rien d’autre. II s’agit done de changer de posture et d’adopter la 
culture et le sens du service. Au meme titre qu’un restaurateur ou 
qu’un commenjant, toute entreprise qui vend du service doit connai- 
tre et comprendre mieux que quiconque son produit et ses services : 
les Directions des Systemes d’information de nos entreprises sont 
devenues, par la force des choses, des vendeurs de services. 

Et alors ? Eh bien ! vous conviendrez que devenir un producteur de 
services ne represente pas du tout le meme objectif qu’atteindre le 
niveau 5 de tous les processus ITIL (ou autres normes et standards 
emergents). Devenir une Production de Services consiste a accompa- 
gner toute l’entreprise dans le cadre de processus alignes avec l’enjeu 
des clients. Cette vision peut paraitre simpliste. Pour devenir un j 
producteur de services, c’est facile, il me suffit de dessiner des J> 
processus alignes avec le client. La demarche est en fait legerement | 
plus pragmatique qu’il n’y parait. . . ® 
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Devenir un producteur de services signifie que toute reorganisation 
de la DSI et tous les corps de metiers qui la composent doivent etre 
tournes vers la qualite du service fournie. Et au lieu de parler de : 

• conception systeme ; 

• developpement applicatif ; 

• test applicatif ; 

• production metiers ; 

• exploitation technique, 

il faut maintenant discuter de : 

• conception de services ; 

• developpement de services ; 

• test de qualite de service ; 

• production de services ; 

• exploitation de services. 

Un moyen de verifier que votre organisation est alignee (sur le 
terrain et dans les esprits) sur la qualite de service consiste a inter- 
viewer vos ingenieurs, vos techniciens, vos architectes techniques, en 
leur demandant de vous exposer leur objectif quotidien. Si, dans 
leurs reponses, les mots qualite et service sont formules, alors le 
changement est en train d’operer et vous etes fin pret pour relever ce 
defi aujourd’hui. 



Chapitre 1 

Pourquoi la gestion des problemes ? 


Comment ameliorer la qualite de services 

Cette partie a pour objectif d’aborder les leviers de Vamelio- 
ration de la qualite de service ainsi que leur mise en oeuvre 
par le biais du processus de gestion des problemes. 

Nous apporterons des reponses aux questions suivantes : 

Pourquoi la gestion des problemes est un processus qui 
permet Vamelioration de la qualite de service ? 

Sur quels points precis faut-il agir pour ameliorer la qualite 
de service ? 


Avant de rechercher la qualite de service, quoi de plus perspicace 
que d’en comprendre au prealable la signification ? Qu’est-ce que la 
qualite ? Qu’est-ce qu’un service ? Visitons les definitions de la littera- 
ture normative. Sur la qualite : 

• Aptitude d’un produit ou d’un service a satisfaire, au moindre 
cout et dans les moindres delais, les besoins des utilisateurs 
[ISO 9000 : 1982], 

• Ensemble des proprietes et caracteristiques d’un produit ou d’un 
„ service qui lui confere l’aptitude a satisfaire des besoins exprimes 
| ou implicites [ISO 9000 : 1987]. 

| • Ensemble de caracteristiques d’une entite qui lui confere l’aptitude 

| a satisfaire des besoins exprimes ou implicites [ISO 9000 : 1994]. 
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• Aptitude d’un ensemble de caracteristiques intrinseques a satis- 
faire des exigences [ISO 9000 : 2000], 

Sur le service : 

• Travail fourni par quelqu’un et qu’on lui remunere. 

Activite du secteur tertiaire, qui ne produit pas de biens materiels. 
[Dictionnaire de la langue frangaisej 

A partir de ces quelques definitions, si l’on s’interesse a l’expression 
« qualite de service », on comprend deja que le beneficiaire du 
service est le client, et que sa qualite est en rapport avec ses exigen- 
ces. On comprend mieux pourquoi la qualite de service est le Graal 
qui fait courir de nombreuses entreprises. Plus elle s’ameliore, plus 
vous etes en phase avec vos clients et done plus vous les fidelisez. 

Pour pouvoir parler d’amelioration de la qualite de service, il faut 
done definir les exigences de depart, celles qui vont permettre de 
borner la qualite attendue, mais aussi definir le systeme de mesure et 
le suivi de cette qualite : 

• La definition des exigences de qualite de service reside dans la 
consolidation du contrat de service (Service Level Agreement). 

• Les mesures sont definies par la construction des indicateurs de 
niveaux de services. 

• Les niveaux de services sont suivis par l’examen des indicateurs, 
par l’analyse des causes de non-respect de ces indicateurs et par 
l’identification du plan d’action d’amelioration du niveau de servi- 
ces non respecte. 

Ces 3 points font parties integrantes du processus de gestion des 
niveaux de services. Celui-ci est done necessaire dans la course a 
l’amelioration de la qualite de service et va notamment permettre de 
dessiner le terrain de jeu (quel niveau de service faut-il atteindre ?) et 
de montrer la marge de progres a franchir (quel est le niveau de 
service actuel ?). Une fois cet etat de fait etabli, la question de 
l’amelioration de la qualite de service reste ouverte. 

Dans une logique un peu basique (mais qui neanmoins reste vraie 
quel que soit le contexte), lorsque les clients se plaignent de la 1 
qualite de service, on observe : ‘e 

| 

• soit qu’ils sont en train de faire « la descente aux enfers » ; ® 
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Sla Courbe de tendance 


Figure 2-1 : Gabarit n° 1 d’indicateurs de services en baisse 


• soit qu’ils sont en train de faire « le grand huit ». 


Indicateurs de services respectes sur 12 mois 



Figure 2-2 : Gabarit n° 2 d’indicateurs de services en baisse 


I Une chose est certaine : le client n’accorde pas sa confiance a une 
| qualite de service qui lui fait vivre les sursauts et les remous d’un 
| manege de pare d’attractions. Une fois que vous avez integre le fait 


24 Ameliorer la qualite des services 


que la qualite de service est l’objectif, vous etes fin pret a compren- 
dre qu’ITIL est un cadre de reference qui va vous aider a travailler sur 
cette brique manquante au sein de votre organisation : la qualite de 
service perenne au meilleur cout. 

Au sein des DSI, il est courant de constater qu’une gestion des inci- 
dents existe. C’est un processus dont le besoin de mise en place se 
ressent tres tot. Seulement bien souvent, il manque le processus 
complementaire appele gestion des problemes. Si le souci est 
d’ameliorer la qualite de service, il nous faut une approche de resolu- 
tion des problemes de qualite ! C’est cette demarche qui va permettre 
de maitriser les effets de descente aux enfers ou de grand huit. 

Pour ameliorer la qualite de service et done maitriser ces effets nega- 
tes, il faut pouvoir agir sur trois facteurs de nuisance : 

• Diminuer les impacts des incidents sur les services pour tenir la 
rampe de l’objectif. 

• Anticiper l’effet d’erosion des services pour eviter les risques de 
chute longue et/ou vertigineuse de la qualite de service. 

• Accelerer le retablissement de services en cas d’impact suite a un 
incident. 

Si vous cherchiez le moyen de mettre le client au coeur de la DSI, 
vous venez de le trouver. Mais faut-il le rappeler, le plan de transfor- 
mation de l’organisation de la DSI engage des couts et des modifica- 
tions de fonctionnement au plus proche des habitudes prises par les 
equipes. Il s’agit bien d’un processus transversal a la DSI, dont 
implementation est a considerer comme un veritable changement 
global, un reel objectif de management. 

C’est enfin un projet qui doit etre accompagne par la volonte de 
toute la DSI. Pourquoi ? Certainement pas pour se faire plaisir, mais 
parce que le processus de gestion des problemes va aligner l’inter- 
vention de tous les niveaux d’expertise de la DSI dans un seul et 
meme mode de fonctionnement structure. Il va concerner autant le 
metier des tests, les metiers de la production et de l’exploitation que 
les metiers des developpements (comme les maitrises d’oeuvres), ou 
encore les metiers de l’hebergement. g 

Il est clair qu’un bon processus de gestion des problemes est un |j> 
maillon essentiel pour (amelioration de la qualite de service. Nous | 
disions precedemment que les incidents surviennent les uns apres les ® 
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autres et finissent par transformer la vie du client de la DSI en un 
veritable cauchemar (et generalement il nous le rend bien). Alors, 
comment puis-je ameliorer mon engagement de services, celui que la 
DSI a pris vis-a-vis de mon client, sur mon perimetre de 
responsabilites ? 

Trois messages sont a se rappeler : 

• diminuer l’impact des incidents ; 

• anticiper les risques de chute (l’erosion) ; 

• accelerer le retablissement. 

En resume, il n’y a pas de magie ! Pour ameliorer la qualite de 
service, la DSI a besoin de limiter les impacts negatifs lies aux inci- 
dents dont la nuisance abaisse la tenue et le maintien de ses engage- 
ments de services. La methode apportee par le processus gestion des 
problemes est un moyen de mettre en place et de faire vivre cet 
objectif en eradiquant (ou en reduisant a son minimum) l’impact des 
causes structurelles de la non-qualite de service, ce qui aura pour 
effet double de : 

• Reduire le delai de resolution des incidents par l’augmentation et 
la centralisation de la capitalisation. Il va etre possible de mettre 
en oeuvre rapidement la solution permettant de contourner une 
faille du systeme informatique, de la fagon la plus efficace possi- 
ble (contre toute attente, cela ne depend pas uniquement du 
processus de gestion des incidents). 

• Diminuer l’impact des incidents sur la qualite de service par la 
mise en oeuvre de solutions qui vont permettre d’empecher la 
reproduction des impacts associes. Cela permettra d’eviter les 
risques de repercussions extremes sur les activites de l’entreprise 
et/ou son image de marque. 

Le schema 2.3 decrit le modele a retenir. 

L’equation de l’amelioration de la qualite de service peut s’ecrire 
ainsi : 


La quality de service Si (Degr6 d'impact x D6lai de resolution) 
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Figure 2-3 : Les parametres influant sur la qualite de service (QoS) 


La qualite de service augmente si le binome (degre d’impact x delai 
de resolution) baisse. 

La non-qualite de service (non QoS) est proportionnelle au degre 
d’impact occasionne sur le service ainsi qu’au delai de resolution des 
incidents sur le service. De cette equation, nous declinons le modele 
de la figure 2.4. 

La cle du modele est le processus de gestion des problemes. C’est 
une cle organisationnelle et culturelle avant tout. 

En conclusion, tout l’enjeu de cette course a la qualite de service 
reside dans la capacite que va avoir la DSI a s’approprier de J 
nouveaux principes de gestion et de resolution des problemes de la J- 
non-qualite de service, en les adaptant a son contexte a un cout opti- | 
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Degre d'impact X Delai de resolution 



structurelle 

Figure 2-4 : Equation et ecosysteme de I’amelioration de la QoS 


Quelques notions de vocabulaire 

Cette partie a pour objectif de presenter la definition des 
termes probleme et erreur connue. 

A ce stade, I’idee est de commencer a se familiariser avec le 
sens de ces deux mots cles pour apprehender la comprehen- 
sion du processus de gestion des problemes. 

Nous apporterons des reponses aux questions suivantes : 

| Quelles differences entre un probleme et une erreur 
'S connue ? 

| Comment un probleme devient-il une erreur connue ? 
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Comme nous l’abordions precedemment, nous retenons que 
nombreuses sont les entreprises qui ont mis en route une gestion des 
incidents, mais pas des problemes. Une des raisons tient au fait que 
la distinction entre un incident et un probleme n’est pas evidente... 

Si les notions d’incidents et de problemes sont considerees comme 
identiques, la mise en place d’une gestion des problemes ne presente 
plus d’interet. Pour comprendre que le mot probleme n’est pas un 
synonyme d’incident dans notre vision processus, il devient impor- 
tant de comprendre la difference entre le retablissement de service 
(vise par la gestion des incidents) et la resolution des causes (visee 
par la gestion des problemes). 

A ce stade, lister tout le vocabulaire de la gestion des problemes n’est 
pas essentiel. L’idee n’est pas de parler couramment de la gestion des 
problemes avec ITIL. L’enjeu est avant tout de comprendre ce qu’est 
vraiment un probleme. Ce mot est a priori bien connu dans notre 
vocabulaire courant. Par exemple : j’ai un probleme avec ma 
voiture ; elle ne demarre plus. 

Mais dans le cadre de la gestion des problemes, le terme probleme 
designe la cause inconnue et non l’effet constate. Dans l’exemple cite 
ci-dessus, ce que nous avons nomme comme etant le probleme fait 
intervenir deux vocables bien distincts dans une traduction propre a 
celle du processus de la gestion des problemes : 

• J’ai un incident avec ma voiture : elle ne demarre plus. L’angle de 
lecture du processus traduit que nous sommes orientes vers l’effet 
constate du dysfonctionnement. 

• J’ai un probleme avec ma voiture : elle ne demarre plus. Cette 
fois-ci, l’approche processus exprime que nous nous interessons a 
la cause inconnue du dysfonctionnement. 

En d’autres termes, l’incident caracterise l’effet par lequel le symp- 
tome du dysfonctionnement se manifeste, tandis que le probleme 
caracterise la cause inconnue par laquelle le symptome du dysfonc- 
tionnement se produit. 

Cette difference est primordiale car les actions a entreprendre, 
suivant que nous traitons l’effet ou la cause, sont complementaires g 
mais bien distinctes l’une de l’autre. En effet : 1 

• Dans le premier cas, si je souhaite traiter l’effet, la solution la plus | 
rapide va consister a rechercher tous les moyens possibles pour la ® 
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contourner. En rapport a l’exemple precedent, une solution de 
contournement pourrait etre de prendre un taxi. 

Dans le deuxieme cas, si je souhaite traiter la cause inconnue, il me 
faut d’abord et obligatoirement la decouvrir. Une fois la cause 
connue, je saurai comment la contourner de la maniere la plus effi- 
cace possible, ou mieux, m’en debarrasser de fagon definitive. En 
reprenant l’exemple precedent, si apres un diagnostic approfondi je 
decouvre que la cause du non-demarrage de ma voiture est une 
panne d’essence et que ma jauge d’essence n’a pas suffi a me 
permettre de reagir a temps, une solution de contournement efficace 
consisterait a faire le plein et a mettre en place un controle manuel et 
regulier pour pallier la fonction defectueuse de ma jauge d’essence. 
Une solution definitive residerait dans la reparation de cette jauge 
d’essence defectueuse. 


Dans le processus de gestion de problemes, il faut retenir les deux elements 
suivants. 

Un probleme est la cause sous-jacente inconnue d’un incident significatif 
(incident majeur) ou de plusieurs incidents presentant les memes symptomes. 
Un probleme devient une erreur connue lorsque la cause sous-jacente du ou 
des incidents est connue, qu’une solution de contournement a ete trouvee et 
qu’aucune solution definitive n’est deployee. 


En conclusion, un probleme est une cause que Ton ne connaTt pas et 
qui genere soit un incident dont l’impact est extreme pour l’entre- 
prise, soit plusieurs incidents dont les impacts cumules tendent a 
amoindrir la qualite de service. 

C’est uniquement lorsque cette cause est trouvee, et qu’une solution 
provisoire permettant de canaliser cette cause est mise en place, que 
nous pouvons parler d’erreur connue. Celle-ci correspond done au 
statut d’un probleme localise avec succes par l’identification de sa 
cause premiere et le developpement d’une solution provisoire. 

Un autre point de vocabulaire est important pour la suite. Les expres- 
sions solution provisoire, solution palliative et solution de contourne- 
ment sont des synonymes. Cependant, ces termes appellent selon le 
contexte une autre nuance (et non des moindres) vis-a-vis de 
| laquelle il faut etre vigilant. 

I 

o 

© 
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Dans le cadre de la gestion des incidents 

Une solution provisoire (ou palliative, ou de contoumement) a pour 
seul objectif de retablir le service dans les delais les plus courts et 
conformement au contrat de service signe (c’est le moyen mis en 
oeuvre pour atteindre Pobjectif du processus de gestion des incidents). 
L’aspect temporaire des moyens mis en oeuvre pour la resolution d’un 
incident est ici juge par rapport au caractere peu perenne de la solu- 
tion mise en place. C’est une solution dont il faut s’attendre a devoir 
repeter la mise en oeuvre autant de fois que l’incident apparaitra. 

Dans le cadre de la gestion des problemes 

Une solution provisoire (ou palliative, ou de contoumement) a pour 
objectif d’amoindrir le potentiel de nuisance des causes de non- 
qualite de services et/ou de diminuer les risques de reapparition des 
incidents associes a ces causes. L’aspect temporaire des moyens mis 
en oeuvre pour la resolution d’un probleme est egalement evalue par 
rapport a l’aspect ephemere de la solution mise en place pour repon- 
dre a l’objectif vise. La solution definitive doit ensuite permettre 
d’annuler definitivement le risque de reapparition de (ou des) inci- 
dents) associe(s). 


Dans le cadre du processus de gestion des problemes, « Probleme » et 
« Erreur connue » sont deux statuts dans le cycle de vie du processus. Pour 
etre exact, le processus aurait pu s’appeler « Processus de gestion des 
problemes et des erreurs connues ». 


Vous trouverez ci-dessous un exemple de cycle de vie caracterisant 
les etapes cles du processus de gestion des problemes. 

L’erreur connue fait partie du cycle de vie du traitement d’un 
probleme. Dans une vision synthetique de 1’evolution du dossier 
probleme, nous pouvons retenir le schema de la figure 2.6. 

Quelques elements pratiques a prendre en compte 

Tous les incidents ne font pas obligatoirement l’objet d’un probleme. I, 
Toutes les erreurs connues ne font pas forcement l’objet d’une reso- | 
lution et done de la mise en place d’une solution definitive. ® 
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Figure 2-5 : Cycle de vie du traitement d’un probleme 


Appels 


Centres de services 



Incidents 

Gestion des incidents 

Problemes 

Gestion des problemes 


Erreurs connues 


Gestion des changements 

Changements 


Figure 2-6 : Modele devolution des differents types de dossiers 
operationnels 
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Le diagnostic des problemes necessite du temps et peut dans certains 
cas repousser le delai de retablissement du service. 

Solution provisoire vaut mieux que solution definitive dans certains 
cas. II est alors preferable d’opter pour l’implementation d’une solu- 
tion de contournement permanente. 

Ce type de solution est aussi une solution de contournement (provi- 
soire ou palliative) telle que definie precedemment. Cette solution 
sera en complement identifiee comme permanente car le retour sur 
investissement des solutions definitives etudiees n’est pas viable. 

Un moyen eprouve permettant de s’assurer d’avoir correctement 
cerne la cause sous-jacente du probleme consiste a observer le 
comportement du service apres la mise en place de la solution provi- 
soire. Dans les faits, il est done conseille de considerer le passage 
reel du probleme vers le statut d’erreur connue a la fin de cette 
periode d’observation. Cela permet de verifier que la solution provi- 
soire implementee est efficace. 

Nous savons ce qu’est un probleme, ce qu’est une erreur connue, 
mais alors que penser de ces expressions de la culture ITIL : une 
erreur inconnue, un probleme connu, une erreur. 

Voici en figure 2.7 un decryptage pour que ces expressions plus ou 
moins deroutantes n’aient plus aucun secret pour vous. 




Figure 2-7 : Paralleles entre probleme et erreur 
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Benefices de la Gestion des Problemes 

Cette partie a pour objectif de decrire I’ensemble des benefi- 
ces pouvant etre obtenus suite a la mise en place du proces- 
sus de gestion des problemes. 

Nous verrons qu’ils sont le fruit de l ’amelioration de la qua- 
lite de service par effet direct ou indirect. 

Nous apporterons enfin des reponses a des questions 
comme : 

Quels sont les differents types de benefices attendus par la 
mise en place du processus de Gestion des Problemes ? 

Que risque-t-on dans le cas oil le processus de gestion des pro- 
blemes n’est pas mis en place ? 

Vous l’avez compris, le principal acquis suite a l’implementation du 
processus de gestion des problemes est un gain sur la qualite de 
service. Cela tombe plutot bien : c’est ce que veulent les clients. Mais 
plus precisement, quels sont les avantages inherents a cette demarche ? 
Ce processus s’inscrit de fagon naturelle et visible dans un cycle 
d’amelioration continue, cela au benefice : 

• De la qualite de service et des activites de l’entreprise, par : 

- L’amelioration de la tenue des engagements de niveaux de 
services. 

- L’amelioration de la perception des services IT par les clients 
et utilisateurs de la DSI dont la satisfaction ira en s’ameliorant 
pour atteindre le stade de la confiance. 

- L’amelioration de la perception des services IT par les collabora- 
teurs de la DSL C’est une perception qui compte. Les collabora- 
teurs sont aussi des clients de l’entreprise et 1 ’effet galvanisant 
des victoires qui font reculer la non-QoS (non-qualite de 
service), apportent progressivement le ciment qui rend l’organi- 
sation etanche a cette non-QoS : c’est la culture du service. 

- L’amorce reelle d’un cycle d’amelioration continue et rapide de la 
qualite de service par la prevention des risques de la non-QoS. 

• De la reduction des couts de support au service, par : 

- La mise en place de solutions permettant d’eradiquer les 
causes structurelles de non qualite de service sur le systeme 
d’information. 
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• D’une capacite croissante d’auto-apprentissage des collaborateurs 

(particulierement les acteurs de la gestion des incidents, des chan- 

gements et des problemes), par : 

- La mise en place de la documentation et la tragabilite des solu- 
tions issues de la recherche mise en oeuvre dans le cadre du 
processus. 

- La concretisation du concept d’apprentissage puisee dans 
(experience passee par Paralyse des tendances et la conserva- 
tion des solutions (capitalisation). 

- Un meilleur taux de resolution des incidents au l er niveau de 
support. 

• De la rapidite du retablissement de service maftrisee par les 

supports techniques qui traitent en l er niveau par : 

- Le processus de gestion des problemes entramant l’effort 
d’industrialisation du systeme d’information, la maitrise du 
savoir-faire et la culture du zero defaut permanent en lieu et 
place de la culture de l’exploit. 

• De l’alignement de la DSI avec les enjeux de nos clients par : 

- La mise en oeuvre de chantiers d’amelioration visant a combat- 
tre la non-QoS en coherence avec les besoins des Directions 
Clients. Ce type de chantier permet de concretiser l’alignement 
entre DSI et les directions clients et d’allier leurs forces contrai- 
rement au passe ou elles s’opposaient frequemment. 

• Du marketing de la DSI vis-a-vis des directions clients par : 

- L’amelioration du dialogue entre les clients et la DSL 

- L’amelioration de la communication entre les clients et la DSL 
Cette derniere communique, montre et publie des resultats qui 
interessent le client, a savoir les actions concretes mises en 
oeuvre pour l’amelioration de son service. 

• D’une meilleure sante du systeme d’information, par : 

- la reduction du volume d’incidents ; 

- la reduction des incidents avec fort impact (amelioration de la 
QoS) ; 

- la reduction des interruptions dans les activites au coeur du 

metier de l’entreprise. j 

Identifier la cause reelle de l’apparition d’un (ou plusieurs) inci- J- 

dent(s) vise indirectement, et par construction meme du processus, a | 

reduire le volume des incidents sur le systeme d’information, et en ® 
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particulier le volume des incidents recurrents. C’est une bonne 
nouvelle pour le Centre de services qui va pouvoir souffler ! Mais 
faut-il le rappeler, ce n’est pas l’objectif du processus. 

Void un exemple d’illustration : une entreprise a mis en place le 
processus de gestion des problemes debut mars. Entre mars et avril, 
les acteurs du processus ont enregistre 45 problemes et en ont 
cloture 20. Le tableau ci-dessous liste les problemes clotures et le 
nombre d’incidents associes. 


Probleme clos 
au mois de mars 

Nombre d’incidents/mois 
associe par probleme clos 

Priorite du probleme 

Probleme n° 1 

2 

PI 

Probleme n° 2 

8 

P2 

Probleme n° 3 

4 

P3 

Probleme n° 4 

2 

PI 

Probleme n° 5 

10 

P3 

Probleme n° 6 

84 

P3 

Probleme n° 7 

4 

PI 

Probleme n° 8 

36 

P3 

Probleme n° 9 

8 

P3 

Probleme n° 10 

6 

PI 

Probleme n° 1 1 

16 

P2 

Probleme n° 12 

2 

PI 

Probleme clos au 
mois d’avril 

Nombre d’incidents/mois associe 
par probleme clos 

Priorite du probleme 

Probleme n“ 13 

1 

PI 

Probleme n° 14 

36 

P3 

Probleme n° 15 

9 

P3 

Probleme n° 16 

26 

P3 

Probleme n° 17 

10 

P3 

Probleme n° 18 

24 

P2 

Probleme n° 19 

6 

P3 

Probleme n° 20 

6 

P2 


Tableau 2-1 : Exemple de problemes clos 
| et du nombre d’incidents associes 

I 

| Les problemes de haute priorite ne sont pas ceux auxquels sont asso- 
| cies le plus grand nombre d’incidents. 
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La reduction du nombre d’incidents s’illustre par le graphique de la 
figure 2.7. Si cette entreprise n’avait pas mis en place son processus 
de gestion des problemes, elle aurait enregistre +14,4 % d’incidents 
sur le mois d’avril et + 26,7 % sur le mois de mai. 


Nombre d'incidents depuis debut janvier 



— Nb d'incidents apres GDP — Nb d'incidents sans GDP 
-- Courbe de tendance du nb --- Courbe de tendance du nb 
d'incidents apres GDP d'incidents sans GDP 


Figure 2-8 : Exemple de representation de la diminution des incidents 
par le traitement des problemes 

A contrario, la non implementation du processus de gestion des 

problemes entraine a minima : 

• du point de vue de la qualite de service : 

- Le risque d’apparition d’incidents dont l’impact est extreme 
pour l’entreprise et les utilisateurs. 

- Une qualite de service difficile a perenniser. Des niveaux de 
services non atteints de fagon reguliere. Generalement, cela 
transpire au travers d’indicateurs de service ou Ton peut distin- 
guer un effet de montagnes russes. 

- Un manque de leviers pour l’atteinte du niveau d’exigence 
demande par le client. 

• du point de vue du systeme d’information : 

- Une fragilisation du systeme d’information par l’augmentation 

des risques de rupture de service et l’aggravation des impacts J 
pouvant etre engendres sur le service. J> 

- Un recul de la capacite a maltriser la technologie du systeme | 

d’information. ® 
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• du point de vue de l’organisation : 

- Une organisation du support purement reactive, n’intervenant 
que lorsque les utilisateurs sont deja immobilises et leur 
donnant l’impression d’etre les superviseurs du systeme 
d’information. 

- Une organisation confrontee a des incidents recurrents abais- 
sant la qualite de service et entrainant une perte de confiance 
des utilisateurs, quant a la capacite de l’organisation a mainte- 
nir la qualite de service. 

- Une organisation de support inefficace, avec des couts prohibi- 
tifs. Chaque expert est face a lui-meme, traitant le sujet qui 
l’interesse sans assurance d’etre en harmonie avec les priorites 
du client. 

- Une organisation qui a des difficultes a se projeter pour antici- 
per les moyens necessaires pour le maintien de la qualite de 
service. 

- Une organisation qui perd sa capacite d’expertise et se centre 
dans une competence generique. 

• du point de vue du Centre de services : 

- Un Centre de services demotive, a cause de la repetitivite du 
travail face aux incidents recurrents pour lesquels aucune solu- 
tion structurelle n’est apportee et qui n’a plus le courage de 
faire de son mieux pour satisfaire les attentes des clients. 

- Une baisse de la connaissance du Centre de services, done une 
augmentation des escalades techniques et done des delais de 
traitement des incidents. 

- Une image defavorable du Centre de services qui sera decriee 
par les utilisateurs, les clients et l’interne pour son inefficacite 
et son peu de valeur ajoutee. 

• du point de vue de la capitalisation : 

- La non-persistance de la connaissance. 

- L’absence de documentation pertinente et a jour pour le traite- 
ment des incidents et des problemes. 

Facteurs cles de succes 

Cette partie a pour objectif de faire etat des recommanda- 

tions a suivre afin de garantir le succes de la mise en oeuvre 

du processus de gestion des problemes. 
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Ces recommandations sont des imponderables qniferont la 
difference dans la reussite du processus quant a I’atteinte de 
ses objectifs pour Vamelioration de la qualite de service. 

Nous apporterons des reponses aux questions suivantes : 

Que faut-il faire pour mettre en place un terrain propice a 
la mise en oeuvre du processus ? 

Comment preparer ce terrain ? 

Lesfacteurs de succes dans la conduite du changement du 
processus de gestion des problemes sont de plusieurs ordres. 

Gerer la complexite du changement 

Le processus de gestion des problemes possede la particularite d’etre : 

• Interdependant avec d’autres processus. Les elements d’entrees/ 
sorties sont imbriques de fagon importante avec les autres proces- 
sus (par exemple avec la gestion des incidents, la gestion des 
changements, la gestion de la capacite, de la disponibilite, etc.). 

• Enchevetre dans une interaction transversale a plusieurs structu- 
res de la direction (maitrise d’oeuvre, support test, support 
d’expertise en production, architectes techniques, hebergeur). 

• Une remise en cause des habitudes natives du reflexe. Le naturel 
pousse a traiter l’effet d’un dysfonctionnement mais rarement a 
traiter sa cause. C’est un processus qui va done necessiter d’enga- 
ger une modification plus ou moins importante des comporte- 
ments de l’organisation. La part d’incertitude quant a la 
profondeur de la modification a realiser conditionne un niveau de 
complexite a part entiere. 

S’approprier le but vise 

Chaque acteur devra etre tenu informe de la volonte de l’entreprise 
au travers de la mise en oeuvre d’un processus de gestion des proble- 
mes et devra comprendre pourquoi l’organisation engage une telle 
demarche de changement. II s’appropriera l’envie de reussir dans 
l’atteinte des objectifs formules par l’organisation, e’est-a-dire de g 
developper des competences en conduite du changement 
11 existe differentes approches de conduite de changement. Quelle que | 
soit l’approche adoptee, il va de soit que la competence d’accompa- ° 
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gnement au changement sera un bras arme pour la reussite de la mise 
en place du processus de gestion des problemes. Meme s’il n’existe 
pas de recette miracle, on constate par exemple que : 

• L’engagement et l’implication de la direction jouent un role 
majeur et preponderant dans le succes de la conduite du change- 
ment organisationnel. N’oubliez pas que la mise en place du 
processus de gestion des problemes est un changement organisa- 
tionnel a part entiere. La direction doit done assumer des respon- 
sabilites concernant l’organisation et ses modifications. II est 
conseille que la direction ait un role d’acteur plus que de specta- 
teur et de censeur. 

• Les changements d’envergure sont neanmoins a conduire avec le 
plus grand soin et la plus grande vigilance. L’experience montre 
que plus de 60 % des changements aboutissent a un echec ou un 
semi-echec. Pour une grande part, ces echecs sont dus a une defi- 
cience en matiere de conduite du changement sur un plan 
humain. Ils se caracterisent par les 5 points suivants : 

- la prise en compte du passe des acteurs, de leur histoire, de 
l’existant au sein de l’organisation ; 

- l’adaptation de la communication ; 

- la mobilisation des ressources de l’organisation et la capacite 
du management a federer ; 

- la legitimite et la credibility des conducteurs du changement ; 

- le dispositif de pilotage et d’accompagnement au changement. 
Comme nous le disions, il n’y a pas de recette magique pour accom- 
pagner le changement. Nous pouvons neanmoins constater qu’il 
s’agit d’un travail qui doit trouver son essence dans la collaboration 
et dans l’esprit d’equipe. On retiendra neuf criteres de succes en 
rapport avec la conduite du changement : 

• Se donner du temps. 

• Accepter le droit a l’erreur. 

• Prevoir et organiser des essais. 

• Clarifier la vision de l’avenir, afin qu’elle puisse etre transmise de 
la fagon la plus nette possible a l’ensemble des acteurs. 

• Elaborer et suivre une strategic precise dans la mise en oeuvre du 
changement. La mise en place d’un changement ne s’improvise pas. 
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• Piloter le deploiement generalise avec le meme niveau de 
controle que les phases pilotes et les essais a taille reduite. 

• Avoir l’appui actif de la direction qui s’engage, et donner les 
moyens necessaires a 1’aboutissement des objectifs vises. 

• Former et impliquer les equipes. 

Trouver les leaders de la transformation 

implementation du processus de la gestion des problemes necessi- 
tera, certes, que des responsables experts en gestion et en planifica- 
tion se penchent serieusement sur le sujet. Mais ce n’est pas tout. II 
faut veiller a ce que le ou les leaders du plan de transformation a 
mener soient en mesure : 

• De s’inspirer des actions faites sur le terrain pour adapter le 
mouvement de la transformation. 

• De comprendre le present, ses failles et d’anticiper l’avenir, en 
d’autres termes, d’avoir la capacite d’etre visionnaire. 

• De mobiliser toutes les ressources necessaires sur un plan opera- 
tionnel et managerial. La capacite a entrainer tous les acteurs est 
primordiale. La qualite du leadership dans sa force de conviction 
est un atout pour appeler les hommes vers le changement. 

• De comprendre le contexte structurel, conjoncturel et organisa- 
tionnel. C’est la comprehension et la capacite d’anticipation sur 
ces trois dimensions qui vont permettre une certaine maitrise du 
terrain mouvant dans lequel les acteurs vont evoluer. 

• De preferer un maillage des pouvoirs plutot qu’une concentration 
a un endroit donne, c’est-a-dire investir de pouvoir les acteurs qui 
vivent ou doivent vivre le changement. Ce point est crucial pour 
leur permettre de faire preuve d’engagement dans la conduite du 
changement. 

Integrer les specificites ITIL et du processus de gestion 
des problemes 

Si toute vigilance est observee par rapport a certains imponderables, J> 
vous etes sur d’obtenir les benefices de la mise en place de votre | 
processus de gestion des problemes. ® 
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En void quelques-uns : 

• S’assurer d’un enregistrement et d’une classification efficace des 
incidents (ce point est fondamental). 

• Investir dans l’analyse des problemes et promouvoir la notion de 
laboratoire de recherches au sein de la DSI ; considerer aussi que 
le temps passe a cette analyse doit etre separe du temps passe par 
les equipes a « eteindre les incendies » (activites incompatibles). 

• Anticiper les conflits potentiels entre la gestion des incidents et la 
gestion des problemes. 

• Veiller a une bonne cooperation entre les deux processus. 

• S’assurer de (equilibre du plan de charge des equipes de support 
devant intervenir sur les deux processus (incident et probleme) et 
surveiller cet equilibre au quotidien dans le pilotage des activites. 

• Appliquer ITIL avec intelligence, c’est-a-dire en faisant le lien 
entre les preconisations faites par ITIL, les besoins reels de (orga- 
nisation et les solutions possibles dans son contexte. 

• Adapter le processus de gestion des problemes decrit par ITIL a 
son besoin : tout n’est pas a prendre mot a mot ; ITIL ne s’appli- 
que pas a la lettre. Attention au dogme, car s’il est besoin de le 
rappeler, il ne s’agit pas d’une solution, mais d’un moyen. 

• Accompagner le changement (ce point est fondamental) et 
notamment au sein des processus de gestion des incidents et des 
problemes. 

• Mettre en valeur les resultats et faire le point sur les difficultes 
rencontrees pour beneficier de cette experience en augmentant la 
capacite de remise en cause de (organisation . 

• Nommer un responsable de (equipe de gestion des problemes 
(different de celui de la gestion des incidents) et lui donner les 
moyens de la gestion. 

• Enregistrer les problemes et leur donner une reference unique. 

• Mesurer les gains avant et apres les actions pilotees dans le cadre 
du processus afin de promouvoir son interet. 

| • Associer la maitrise d’oeuvre dans les activites du processus. 

| • Prendre des risques. La peur de (echec est un frein a (action. Il 

| est preferable d’operer des essais mesures, plutot que de reporter 
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la mise en oeuvre du processus en l’attente du moment ideal ou 
d’une parfaite preparation. 

• Prendre en compte la dimension humaine et culturelle dans le cadre 
de l’accompagnement du changement (ce point est essentiel). 

• Operer un changement par etapes avec des iterations successives. 
Proscrire une demarche de type « big bang ». 

• Qualifier et hierarchiser les problemes en fonction de leur degre 
d’impact sur la qualite de service. 

• Provisionner au moins 20 % du temps des experts aux activites du 
processus de gestion des problemes. 

• Mettre en place, en cas de manque de temps, une demarche 
d’analyse sur les 5 incidents les plus significatifs enregistres la veille. 

Objectifs du processus de gestion des problemes 

Cette partie a pour objectif de decrire le but du processus de 
gestion des problemes. 

Nous nous attacherons egalement a presenter les particulari- 
ty du processus de gestion des problemes quant a son fonc- 
tionnement et a son execution sur un plan general. 

Nous apporterons des reponses aux questions suivantes : 

Quels sont les principes lies a Vobjectif du processus de ges- 
tion des problemes ? 

Pourquoi Vobjectif de la gestion des problemes n ’est-il pas de 
reduire le nombre d’incidents ? 

Les actions de fiabilisation repondent-elles a Vobjectif de la 
gestion des problemes ? 

Le but de la gestion des problemes est de minimiser les consequences 
negatives que peuvent entrainer les erreurs du systeme d’information 
sur les activites de l’entreprise. Pour ce faire, les acteurs de la gestion 
des problemes recherchent et corrigent ces erreurs afin d’empecher 
l’apparition des incidents et des problemes qui leur sont associes. g 

II s’agit done de proteger le systeme d’information contre les causes J> 
de non qualite de service. Afin d’identifier les vaccins efficaces dans | 
la duree pour maintenir le service au niveau de qualite attendu, la ° 
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gestion des problemes doit investir dans la recherche de la cause 
sous-jacente (comprendre « le virus ») qui engendre la panne du 
systeme d’information et done la rupture ou l’alteration de la qualite 
de service. Une fois la cause sous-jacente identifiee, la gestion de 
problemes identifie le remede qui doit permettre de soigner definiti- 
vement le type de panne analyse. Ce soin passe par la mise en oeuvre 
d’un changement dans le systeme d’information. 

Le processus de gestion des problemes a egalement pour objectif de 
mettre a profit le fruit de ces recherches, en mettant a disposition des 
acteurs qui gerent les urgences (la gestion des incidents) des preconi- 
sations et des bonnes pratiques, afin d’assurer la remise sur pied du 
systeme en panne dans les plus brefs delais. 

II faut egalement comprendre que le processus de gestion des 
problemes s’attarde sur l’observation des situations de dysfonc- 
tionnement, « les situations cobayes », dans le but de saisir les 
circonstances qui expliquent la survenance du dysfonctionnement 
et ce pour mieux l’eradiquer. Pour autant, il n’empeche que la 
notion de delai, meme si elle demeure presente a moindre echelle 
par rapport a la gestion des incidents, reste une preoccupation 
importante. 

Ce n’est pas la rapidite avec laquelle un probleme est traite qui va 
caracteriser l’efficacite du processus (contrairement a la gestion des 
incidents), mais son efficience. Le temps passe a traiter un 
probleme represente un cout, qui, rapproche au gain obtenu sur la 
qualite du service associee, permet d’evaluer le retour sur investis- 
sement. Mais il ne faut pas tomber dans le piege qui consisterait a 
confondre les notions de gain et d’objectif a atteindre. S’il est 
besoin de le rappeler, le pilotage par l’objectif (et non par les gains 
attendus) est essentiel pour la reussite de la mise en place de tout 
processus. 

Prenons l’exemple d’une societe qui definirait son objectif en gestion 
des problemes comme suit : diminution de 30 % sur T4 (trimestre 4) 
2007 (par rapport a T4 2006) du nombre d’incidents avec impact 
client. Un dilemme se pose alors dans le cadre de la mise en oeuvre 
| du processus de gestion des problemes. En toute logique, si je 
I souhaite agir en conformite par rapport au processus, j’aurais envie 
§• de traiter en priorite tous les problemes dont le nombre d’incidents 
| associes est le plus fort. Cela veut done dire que les problemes dont 
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le poids en nombre d’incidents est faible ne seront pas traites en 
priorite. 

Cependant, dans la realite operationnelle, je ne pourrai pas donner 
du sens a un tel objectif car un incident qui risque de mettre en peril 
les activites de l’entreprise fera l’objet d’un probleme que tous les 
acteurs voudront traiter en priorite (et ils auront raison). 

L’ objectif du processus de gestion des problemes 
n’est pas de reduire le nombre d’incidents 

Meme si cet amalgame avec la notion de gains possibles a Tissue de 
la mise en oeuvre de ce processus est plutot tentant, ce raccourci n’en 
reste pas moins errone et risque sur un plan operationnel : 

• Vous viendra-t-il a Tesprit de hierarchiser les dossiers problemes a 
traiter en fonction du nombre d’incidents qui leur sont respective- 
ment associes ? 

• Avec un tel objectif, comment donner du sens a Taction quand 
d’un cote vous aurez besoin de mobiliser vos meilleurs experts 
sur la non-reproductibilite d’un seul incident (parce qu’il a eu un 
fort impact sur les activites), alors que, de l’autre, vous communi- 
quez sur la necessite d’orienter toutes les actions de la gestion de 
problemes vers Tobjectif d’une reduction du nombre d’incidents ? 

• Pour atteindre Tobjectif d’une reduction du nombre d’incidents, 
les acteurs operationnels pourraient avoir l’idee de ne plus enre- 
gistrer tous les incidents avec la meme rigueur ; est-il envisagea- 
ble de prendre un tel risque ? 

• Pensez-vous reellement que Tobjectif de la gestion des problemes 
puisse etre exclusivement quantitatif alors que votre client n’a de 
cesse que de reclamer de la qualite ? 

• Etes-vous sur de pouvoir garantir que la reduction de la quantite 
des incidents entramera obligatoirement Tamelioration de la 
qualite de service et prioritairement sur les services critiques pour 
votre entreprise ? 

• Ai-je moins a me preoccuper du traitement des problemes sur 

mon systeme d’information quand je denombre 600 incidents, s 
plutot que 20 000 ou 70 000 ? | 

• En sachant que 80 % des incidents sont lies a des changements | 
(source Gartner), est-ce a dire que Tobjectif de la gestion des ® 
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changements consiste aussi a reduire le nombre d’incidents ? Ou 
meme a reduire le nombre de changements ? Ou peut-etre est-ce 
la un sous-objectif de la gestion des problemes ? 

A toutes ces questions, la reponse est non, et ce pour une raison 
simple : l’objectif de la gestion des problemes n’est pas de reduire le 
nombre d’incidents. La reduction du nombre d’incidents est une 
consequence intrinsequement liee a la reussite de la mise en oeuvre 
de plusieurs processus ITIL. 

En voici quelques-uns : 

• La gestion des problemes par leur traitement et done la non-repe- 
tition des incidents qui leur sont associes. 

• La gestion des changements par la maitrise de l’analyse d’impacts 
associee aux changements devant etre mis en oeuvre sur le 
systeme d’information. 

• La gestion des incidents par la performance dans la resolution des 
incidents : plus les incidents sont resolus rapidement, moins il y a 
de retard accumule (backlog), et done moins il y aura d’incidents 
declares a un instant t. 

• Le Centre de services par sa capacite a distinguer les demandes 
de services des incidents. 

• La gestion des niveaux de services, par sa capacite a negocier des 
engagements de niveaux de services responsables, e’est-a-dire des 
engagements de niveaux de services qui correspondent avec la 
capacite d’engagement de l’informatique. 

• La gestion de la capacite par sa comprehension des besoins 
metiers (la fourniture des services requis), du fonctionnement de 
l’organisation (la fourniture des services actuels), de l’infrastruc- 
ture des technologies de l’information (les moyens de la fourni- 
ture des services) et par sa capacite a garantir que tous les aspects 
de capacite et de performance des exigences actuelles et futures 
du metier seront couverts de maniere rentable. 

• La gestion de la disponibilite par sa capacite a : 

- Veiller a ce que les services informatiques soient congus de faqon 
a foumir les niveaux de disponibilite requis par les activites. 

- A obtenir, apres une certaine periode, une reduction de la 
frequence et de la duree des incidents qui ont un impact sur la 
disponibilite des technologies de l’information. 
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- Veiller a ce que les deficits de disponibilite des technologies de 
l’information soient reconnus et que des actions correctives 
appropriees soient identifiees et mises en oeuvre. 

On retiendra done que la reduction du nombre d’incidents n’est pas 
l’affaire d’un seul processus (de la gestion des problemes, ou d’un 
autre). Plusieurs processus concourent a diminuer le nombre d’inci- 
dents dans le cadre de l’atteinte de leurs objectifs propres. La diminu- 
tion du nombre d’incidents est un gain qui transpire au travers de la 
mise en oeuvre de plusieurs types de processus, mais n’est en aucun 
cas l’objectif du processus de gestion des problemes. 

L’objectif du processus est de « minimiser Vimpact negatif sur les acti- 
vities de Ventreprise des incidents et problemes causes par des erreurs 
dans Vinfrastructure informatique et prevenir la reapparition des 
incidents induites par ces erreurs » [extrait de l’ouvrage ITIL intitule 
Meilleures Pratiques pour Soutien des Services], 

Etant donne que la gestion des problemes puise son energie dans la 
connaissance des experts, l’une des valeurs ajoutees du processus 
tient dans la mise a disposition et dans l’entretien de solutions de 
contournement documentees, issues des investigations menees, et 
mises a jour par le personnel d’assistance des problemes au benefice 
principal de la gestion des incidents. 

Nous le savons, l’objectif de la gestion des problemes n’est pas 
couramment investi par les habitudes. Nous entreprenons plus aise- 
ment le traitement de l’effet plutot que de la cause. De ce fait, 
l’objectif de ce processus donne lieu a plusieurs ambiguites et 
confusions sur le terrain. De nombreuses questions tournent autour 
de l’identification des pratiques internes qui seraient ou non en 
rapport avec l’objectif de la gestion des problemes. D’autre part, les 
incomprehensions decoulent souvent d’une difficulty a mettre en 
evidence les actions courantes. En effet, il est frequent de constater 
que certains modes de fonctionnement en place sont dans la lignee 
de l’objectif de la gestion des problemes tel que defini. Mais les 
acteurs ne le voient pas sous cet angle et risquent parfois de rein- 
venter la poudre ou de doublonner des modes operatoires qui 
auront la meme finalite. 

= 

Meme si l’objectif du processus est quelque peu contre-nature par 
rapport aux reflexes premiers de nos actions de support (traitement | 
des effets plutot que des causes), il n’en reste pas moins probable | 
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que certaines actions meme tres occasionnelles soient du ressort 
d’une gestion de problemes. C’est couramment le cas pour les inci- 
dents a tres fort impact sur l’activite de l’entreprise. Les faux amis 
de l’objectif du processus de gestion des problemes sont souvent 
reconnaissables dans leur denomination faisant directement ou 
indirectement allusion a l’amelioration de la qualite de service. II 
s’agit bien souvent de dispositifs tels que ceux recenses dans le 
tableau suivant. 


Chantiers d’amelioration 
de la qualite de service 

Actions souvent identifies lors de groupes de travail 
s’apparentant a des mini-projets dont I’objectif est 
d’ameliorer la qualite de service en tirant les legons 
du passe (les incidents qui ont ete nuisibles pour les 
niveaux de services). 

Plans d’action/d’amelioration 
de la qualite de service 

Actions visant a ameliorer la qualite de service dans 
le but d’atteindre les niveaux de services 
contraries (SLA). 

Plans de fiabilisation 
des services 

Actions mises en oeuvre pour perenniser le respect 
des engagements de qualite de service. 
Usuellement, ce type de plan est mis en place pour 
les services importants de I’entreprise. 

Plans de non-reproductibilite 

Actions visant a eviter la reproduction d'un incident 
ou d’un probleme. Generalement engagees sur les 
incidents a fort impact sur I’activite de I’entreprise. 

Projets de qualite de service 

Actions devolution du systeme d’information, 
prevues pour repondre aux exigences de qualite de 
service exprimees par le client. 


Tous ces dispositifs ont pour finalite de minimiser l’impact des inci- 
dents et des problemes sur l’entreprise en visant soit leur non-repro- 
ductibilite, soit leur prevention. Ils s’inscrivent dans l’objectif de 
l’amelioration de la qualite de service et nombreuses sont les organi- 
sations qui assimilent ces types de dispositifs au processus de gestion 
des niveaux de services. Pour distinguer les dispositifs operationnels 
de votre organisation qui entrent dans le cadre de l’objectif de la 
gestion des problemes, de ceux qui entrent dans le cadre de la 
gestion des niveaux de services, il faut retenir que : 

• Le processus d’amelioration continue qui vise a atteindre ou a 
maintenir la qualite de service au niveau du SLA est le processus 
g de gestion des problemes. 

J. • La gestion des problemes reactive doit permettre de gagner et 
I preserver les points de qualite de service necessaires a l’atteinte 
« et/ou au maintien du SLA. 
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• La gestion des problemes proactive doit permettre d’eliminer les 
risques de perte de points de qualite de service qui empeche- 
raient d’atteindre le SLA. 

• Le processus d’amelioration continue qui vise a atteindre ou a 
maintenir la qualite de service au niveau du SLR (Service Level 
Requirement) est le processus de gestion des niveaux de services. 

• Ce plan d’amelioration continue est appele SIP (Service Improve- 
ment Program). 


Niveau 

actuel 


Question de : quels plans 

Question de : quels plans 

d'actions engager pour 

d'actions engager pour 

atteindre et/ou maintenir 

atteindre et/ou maintenir 

mon niveau de jeu sur le 

mon niveau de jeu sur le 

SLA? 

SLR ? 



* ^ 





Gestion des 

Gestion des niveaux 

problemes 

de services 



Gestion 1 Gestion 

SIP : Service 

proactive ; reactive 

Improvment Program 


Figure 2-9 : Distinction entre gestion des problemes 
et gestion des niveaux de services 


Les dispositifs precedemment definis peuvent etre classes selon le 
tableau suivant. 


Dispositifs 

Gestion des problemes 

Chantiers d’amelioration de la qualite de 
service 

Proactive 

Plans d’action ou d’amelioration de 
qualite de service 

Reactive ou proactive 

Plans de fiabilisation des services 

Reactive ou proactive 

Plans de non-reproductibilite 

Reactive 

Projets de qualite de service 

Gestion des niveaux de services 
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Attention, la fin ne justifie pas les moyens ! Chacun de ces dispositifs 
operationnels engage un certain cout. Integrer ces dispositifs dans le 
cadre du processus adequat permet d’ameliorer la qualite de service 
de fagon structuree et efficace. 

En conclusion, il nous faut retenir que l’objectif de la gestion des 
problemes est d’ameliorer la qualite de service au meilleur cout. 

Objectif decline en mode reactif et proactif 

Cette partie a pour objectif de detailler la distinction entre 
I’objectif reactif et proactif du processus de gestion des pro- 
blemes. 

Nous apporterons des reponses aux questions suivantes : 
Qu’est-ce que I’objectif reactif de la gestion des problemes ? 
Qu’est-ce que son objectif proactif ? 

Comment se presente concretement l’ articulation des objec- 
tifs reactif et proactif du processus ? 

Quels sont les sous-processus qui portent les objectif s reactif et 
proactif du processus ? 

Le processus de gestion des problemes doit tirer l’organisation d’un 
mode d’action reactif a un mode d’action proactif. 

La proactivite est une condition cle pour que la qualite de service 
puisse etre systematiquement maintenue au rendez-vous, conforme- 
ment aux attentes des clients. Pour permettre a l’organisation d’etre 
aussi bien reactive que proactive, le processus de gestion des proble- 
mes est decompose en deux sous-processus distincts : 

• le processus de gestion reactive des problemes ; 

• le processus de gestion proactive des problemes. 

Ces deux sous-processus doivent repondre a vos 4 questions 
existentielles : 


I 


Les 4 questions existentielles 
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[ Valeur ] Rapprochement services et indicateurs business 
I Service I Gestion de la capacite, gestion des niveaux de services (SLA, OLA/UC) 
^ Proactif~J Gestion des problemes, des changements, de la disponibilite 
( Reactif J Centre desepri&s, gestion des incidents, gestion des configurations 


^ Chaos Plusieurs Help Desk, decouverte des problemes, . 


Moyen terme Long terme 

Figure 2-10 : ChaTne de maturite ITIL 


• Ou se niche la non-qualite de service ? 

• Comment diminuer la non-qualite de service ? 

• Ou sera la non-qualite de service ? 

• Comment se rendre etanche a la non-qualite de service ? 

La gestion reactive des problemes doit permettre de repondre aux 
deux premieres questions. 


Gestion reactive des problemes 



Figure 2-11 : Leitmotiv de la gestion reactive des problemes 


1 

La gestion proactive des problemes doit permettre de repondre aux | 
deux dernieres questions. ° 


Pourquoi la gestion des problemes ? 51 


Gestion proactive des problemes 


o 



Figure 2-12 : Leitmotiv de la gestion proactive des problemes 


Pourquoi un processus aussi bien reactif que proactif ? 

Rappelez-vous que « la non-QoS est proportionnelle au degre 
d’impact occasionne sur le service ainsi qu’au delai de resolution des 
incidents sur le service ». Pour chasser la non-QoS, il faut aussi bien 
etre reactif dans la resolution des problemes qui abaissent la QoS 
actuelle, que proactif dans la capacite a detecter les premices de 
l’apparition de problemes (et done d’incidents) pouvant generer de 
la non-QoS. Plus vous rencontrez des incidents qui abaissent la 
qualite de service, plus vous mettez du temps a retablir le service 
suite a ces incidents, et plus vous laissez d’espace a la non-QoS. 
Lorsqu’un incident est resolu en 1 heure au lieu de 5 heures, on 
divise par 5 la non-QoS. 

Les aspects reactif et proactif du processus vont permettre a l’organisa- 
tion d’etre agile dans sa capacite a maintenir la qualite de service en 
organisant les actions correctives et preventives de fagon structuree. 

En resume, ameliorer la qualite de service revient : 

• en mode reactif, a rechercher et eradiquer ; 

• en mode proactif, a anticiper et eviter la non-qualite de service. 
Les composantes reactives et proactives du processus de gestion des 
problemes se distinguent par le controle des problemes et le controle 
des erreurs dans le mode reactif, la prevention des problemes dans le 
mode proactif. 

L’objectif global du processus, presente dans le chapitre precedent, 
se decline alors en 4 sous-objectifs bien distincts en fonction des acti- 
vites. 
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Gestion reactive des problemes 


. Controle des problemes 


lentil 

: 

A 


Sous-objectif : id^Sfier 
(Element de configuration par ex.) etfournir 

les solutions de 
elle existent. 


o 


Controle des erreurs 


i Sous-objectif : eradiation des erreurs 
} connues en emett^t vers la gestion 
des changements une demande de 
changement (RRjeten suivant jusqu'ai 
lise en place effectif. 


Figure 2-13 : Sous-objectifs de la gestion reactive des problemes 


Gestion proactive des problemes 



Figure 2-14 : Sous-objectifs de la gestion proactive des problemes 

Le principe, s’il est simple dans son propos, n’en demeure pas moins 
vrai et pragmatique a la fois. Autant dire que la non-QoS n’a qu’a 
bien se tenir ! Le schema qui suit modelise les actions reactives et 
proactives du processus. 

Resumons-nous : 

Le processus de gestion des problemes est reactif : 

• pour la recherche des causes a l’origine de la non-QoS ; 

• pour la suppression des causes de non-QoS ; 

• pour la mise en oeuvre de solutions permettant de minimiser 
l’impact sur la QoS. 

Le processus de gestion des problemes est proactif : 

• pour la detection des problemes avant l’apparition d’incidents 
affectant la QoS. 

8 

1 

a 

l 
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Figure 2-15 : Modele d’actions reactives face aux actions proactives 


Dans la pratique, il est conseille de completer cette surveillance proactive de la 
qualite de service par un controle efficace de I’ensemble du portefeuille de 
changement mis en production (passe, present et futur), effectue par le 
processus de gestion des changements. N’oubliez pas que 80 % des incidents 
sont lies a des changements. 


Relation avec l’objectif de la Gestion des Incidents 

Cette partie a pour objectif de detailler la distinction entre 
Vobjectif reactif et proactif du processus de gestion des pro- 
blemes. 

| Nous apporterons des reponses aux questions suivantes : 

i, 

'S Qu ’est-ce que Vobjectif reactif de la gestion des problemes ? 

| Qu ’est-ce que son objectif proactif ? 


54 Ameliorer la qualite des services 


Comment se presente concretement l’ articulation des objec- 
tifs reactif et proactif du processus ? 

Quels sont les sous-processus qui portent les objectifs reactif et 
proactif du processus ? 

La gestion des problemes recherche la cause inconnue d’un ou de 
plusieurs incidents. Souvent, cet objectif est en conflit avec l’objectif 
principal de la gestion des incidents (retablir le service le plus vite 
possible). En effet, il arrive que la mise en place d’une solution de 
contournement soit antagoniste avec la recherche de la cause. 

Prenons l’exemple d’un accident (crash) sur le systeme : la gestion 
des incidents demandera de redemarrer le systeme immediatement 
afin de minimiser le temps d’indisponibilite du serveur. La gestion 
des problemes demandera, elle, a differer le redemarrage du systeme 
car il pourrait supprimer des fichiers « logs » contenant des informa- 
tions precieuses sur l’origine du crash. Les investigations en gestion 
des problemes peuvent necessiter un certain temps, ce qui pour la 
gestion des incidents est tres prejudiciable, car il differe le retablisse- 
ment du service, meme si au final les actions engagees visent a 
empecher la reproduction de l’incident. 

Nous l’aurons compris, la gestion des incidents et la gestion des 
problemes sont des processus dont les objectifs peuvent etre antago- 
nistes. Pour autant, ce sont egalement deux processus complementai- 
res et il faut surtout bien veiller a systematiquement les rapprocher 
sur l’axe de l’objectif supreme qui reste celui de la qualite de service. 
Dans le cadre de la gestion des problemes, les equipes du support 
informatique sont plus dans une demarche proactive. Ils n’ont qu’une 
mince relation avec les utilisateurs dans la mesure ou celle-ci est lais- 
see a la responsabilite du Centre de services. 

La gestion des problemes est complementaire de la gestion d’inci- 
dents, parce qu’elle a egalement pour finalite de se mettre au service 
de l’efficacite de la gestion des incidents. L’inverse est tout autant 
imperatif. C’est une gestion d’incidents efficace qui contribue a une 
gestion de problemes pertinente et qui apporte des resultats. Ces 
deux processus ont done tout interet a s’harmoniser dans l’organisa- » 
tion avec le plus de pragmatisme possible. 1 

Les problemes qui coutent cher a l’organisation sont de fait ceux dont la | 
priorite devra a fortiori etre prise en consideration sur un plan global. | 
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L’organisation doit rester vigilante a ne pas tomber dans le travers ou 
celui qui crie le plus fort beneficie de la priorite la plus haute. Soyez 
egalement attentif a preserver la noblesse du metier de la gestion des 
incidents dans le cadre du pilotage de votre Centre de services. En 
d’autres termes, les processus de gestion des incidents et de gestion des 
problemes ne doivent pas se faire de l’ombre mutuellement. 

II faut envisager les processus de gestion des problemes et des inci- 
dents comme s’inscrivant dans une chaine en 3 etapes dont les objec- 
tifs sont imbriques de fagon logique et rationnelle : 

• La gestion des incidents va retablir le service au plus vite pour 
minimiser les effets de la non-QoS. 

• La gestion des problemes va rechercher la cause reelle de la non- 
QoS pour d’abord la contourner au mieux (le probleme devient 
alors une erreur connue), puis la supprimer definitivement. 

• Les objectifs du processus de gestion des problemes et celui de la 
gestion des incidents se completent dans une meme chaine (voir 
figure 2.16). 

Les conflits entre ces deux processus sont nefastes. On observe qu’ils 
ont frequemment pour cause sous-jacente que l’organisation et le 
management dans sa globalite accordent un credit plus important et 
plus visible au travail effectue par les experts de la gestion des 
problemes par rapport a celui realise par le Centre de services et sa 
gestion d’incidents. II faut bien comprendre que le fonctionnement 
d’une organisation cloisonnee dans son mode d’action ne profite pas 
a l’interet de l’entreprise. Outre le fait qu’un tel contexte puisse etre 
un facteur de demotivation des acteurs du Centre de services, c’est 
toute l’organisation qui se fragilise lorsque la chaine qui maintient et 
ameliore la qualite de service est rompue. 

Le Centre de services (comme son nom l’indique) est au centre des 
services pergus. Entretenir un climat de cooperation et de synergie 
entre les processus de l’organisation et le Centre de services est un 
gain evident en fluidite du fonctionnement de la gestion des proble- 
mes (entre autres) mais aussi de tous les processus qui la traversent. 
| En resume, une bonne gestion des incidents est cruciale pour faire 
| fonctionner une gestion des problemes. II faut considerer la relation 
I entre ces deux processus comme un seul et meme cycle d’ameliora- 
| tion continue, tel que le montre le schema 2-l6. 
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Figure 2-17 : Cycle d’amelioration continue des bases operationnelles 


Pour que ce cycle puisse fonctionner, la gestion des incidents joue le 
role d’amorce. La performance de ce cycle va done dependre du 
niveau de maturite ou se place la gestion des incidents. Une bonne 
tragabilite des informations sur les incidents est le point revelateur de 
la maturite du processus de gestion d’incidents. II s’agit principale- 
ment des informations suivantes : 

• le contexte de l’incident ; 

• les impacts enregistres ; 

• la cause initiale ; 

• la chronologie des actions menees pour retablir le service ; 

• les axes d’ameliorations identifiees durant la gestion de l’incident. 
D’experience, il est a observer que tous les incidents sur l’environne- 
ment de production de services devraient pouvoir etre mis en forme, 
au moins sur demande, selon le modele du CRIP (acronyme de : 
compte rendu d’incident de production). 

| Des lors qu’une organisation est capable de reunir dans un delai 
court (le lendemain d’un incident) les informations du CRIP, elle a 
I prepare un terrain acceptable pour la mise en route d’une gestion 
| des problemes efficace. 
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Compte Rendu d'lnc 


Libelle de I’incident 


m 


JJ.MM.AA - Enonce factuel des symptomes constates a date et heure de detection par 
h : min ordre chronologique 


Rappel des impacts clients 


Enonce factuel des impacts sur I’entreprise (chiffrage des pertes) et sur le client final 
(chiffrage du nombre de clients touches) 


Mode degrade de service(s) 

Date(s) et 
Heure(s) de 
debut 

Date(s) et Heure(s) 
de fin 

Libelle du (ou des) service(s) en mode 
degrade(s) - cf. contrat de service 

JJ.MM.AA- h : 
min 

JJ.MM.AA- h : min 




Interruption de service(s) 

Date(s) et 
Heure(s) de 
debut 

Date(s) et Heure(s) de 
fin 

Libelle du (ou des) service(s) interrompu(s) - 
cf. contrat de service 

JJ.MM.AA- h : 
min 

JJ.MM.AA- h : min 


| Enonce de la (ou des) cause(s) apparente(s) identifiee(s) lors du traitement de I’incident | 


JJ.MM.AA - Enonce factuel des faits, constats, actions realisees et decisions prises dans 
h : min I’ordre chronologique 


Libelle de I’action 


Norn - Prenom JJ.MM - JJ.MM - h : 


Libelle de I’axe d’amelioration 


Norn -Prenom JJ.MM- JJ.MM -h: 


Figure 2-18 : Compte rendu d’incident de production 

J 

Nous pouvons done conclure qu’il est de bon usage de penser J- 
« CRIP » face a un processus de gestion des incidents mature : si les | 
informations du CRIP ne peuvent etre rendues disponibles sous un ° 
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delai court, cela signifie que le processus de gestion des incidents 
n’est pas suffisamment mur et qu’une gestion des problemes ne 
pourrait pas evoluer sur un terrain defavorable dans un tel contexte. 
Vous l’aurez compris, la relation entre les processus de gestion des 
incidents et des problemes est d’une importance majeure. II faut 
comprendre par la que ce sont deux processus qui ne peuvent fonc- 
tionner l’un sans l’autre ; la maturite de l’un depend de la maturite de 
l’autre et vice versa. 

D’un point de vue strictement fonctionnel, vous trouverez ci-dessous 
les donnees issues de la base des incidents et utilisees par le processus 
de gestion des problemes selon un classement par phase d’activite. 

Detection et enregistrement 

1 . La date et heure d’apparition de l’incident. 

2. La date et heure de detection de l’incident. 

3. Les moyens ayant permis la detection de l’incident. 

Support initial et classification 

4. La date et heure de declaration de l’incident. 

3. Evaluation de l’impact : 

• impact utilisateur(s) ; 

• impact de services ; 

• impact activite/image ; 

6. Le contexte de l’incident et l’historique de son evolution : 

• evenements constates par l’utilisateur ; 

• evenements constates par le niveau 1 (alarmes, traitement infor- 
matique en erreur) ; 

7. La qualification de l’incident : 

• environnement concerne (production, pre-production, Testbed. . .) ; 

• domaine metier concerne par l’impact de l’incident ; 

| • application/systeme technique concernes ; 

I • type de symptomes constates (ralentissement, systeme fige, indis- 
| ponibilite) ; 
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8. La mise en correspondance de l’incident avec un autre du meme 
type deja apparu. 

9. La mise en correspondance de l’incident avec un changement. 

10. La mise en correspondance de l’incident avec un probleme. 

1 1 . La mise en correspondance de l’incident avec une erreur connue. 

12. Le (ou les) service(s) affecte(s). 

13. Le (ou les) engagement(s) de niveaux de services affecte(s). 

14. L’engagement de delai initial convenu pour le retablissement de 
service. 

Investigation et diagnostic 

15. La chronologie des actions effectuees par la gestion d’incidents. 

16. Les constats suite aux investigations effectuees par la gestion 
d’incidents : 

• log ; 

• messages d’erreur ; 

• symptomes techniques constates par les supports ; 

17. Les niveaux de support et competence(s) declenches pour inves- 
tigation. 

18. La cause initiale identifiee lors de la gestion de l’incident. 

19. Les anomalies de production detectees durant la gestion de l’incident. 

Resolution et retablissement 

20. Le detail des actions de resolution appliquees durant la gestion 
de l’incident ainsi que leur duree : 

• la reference des documents appliques ; 

• la reference des consignes appliquees ; 

• la duree des actions appliquees ; 

21. Le code cause renseigne lors de la cloture technique de l’incident. 

22. Le detail des actions de rattrapage appliquees durant la gestion 
de l’incident ainsi que leur duree : 

• la reference des documents appliques ; 

• la reference des consignes appliquees ; 

• la duree des actions appliquees. 
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Cldture 

23. La date et l’heure de fin de l’acte de resolution technique ; 

24. Le detail des actions mises en oeuvre pour verifier le retablisse- 
ment du (ou des) service(s) ainsi que leur duree ; 

25. La date et l’heure de retablissement du service valide par 
l’utilisateur ; 

26. Le temps passe sur la gestion de l’incident. 

Rappelez-vous que les objectifs du processus de gestion des proble- 
mes et celui de la gestion des incidents se completent dans une 
meme chaine. Pour que celle-ci soit la plus efficace possible, les trois 
bases de donnees de ces processus doivent pouvoir communiquer et 
faire partie d’un systeme integre. II s’agit de la base des incidents, de 
la base des problemes et de la base des erreurs connues. 

Lors de la declaration d’un incident, il est conseille de suivre une 
procedure qui va permettre de mettre a profit les interactions en place 
entre les deux processus. La figure 2-18 decrit le procede de mise en 
relation entre les incidents, la gestion reactive des problemes. 

La mission de la Gestion des Proble m es 

Cette partie a pour objectif de presenter les missions du pro- 
cessus de gestion des problemes. 

Vousy trouverez essentiellement les recommandations orga- 
nisationnelles pour la mise en oeuvre du processus dans 
I’etat d’esprit qui le caracterise. 

Nous apporterons des reponses aux questions suivantes : 

Quels sont les choix organisationnels recommandes pour la 
mise en place du processus de gestion des problemes ? 

Quel type defonction mettre en place ? 

Quels moyens ? 

«, La mission principale du processus de gestion des problemes est de 
| resoudre definitivement et si possible rapidement : 

I • Les problemes, en particular ceux qui generent des incidents qui 
| coutent cher a l’entreprise. 
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Figure 2-19 : Correlation des incidents 


Pourquoi la gestion des problemes ? 63 


• Les problemes recurrents : 

- concretement, la mission du processus va consister a identifier 
et corriger les erreurs existantes dans le systeme d’information, 
causes de la non-qualite sur les services ou qui presentent un 
risque pour la qualite de service rendue. 

Etant donne qu’il s’agit de traiter les causes et non les effets, une telle 
mission s’accompagne d’un certain savoir etre vehicule par : 

• Un esprit de curiosite. Etre chercheur et savoir reconnaftre les 
signaux d’une situation a risque, meme lorsque tout va bien. 
Mettre en place les actions qui permettront de reduire les causes 
de panne pour limiter les comportements a risque du systeme. 

• Une remise en question. Suis-je le plus performant possible sur 
mon service ? Ai-je mis en oeuvre toutes les precautions possibles 
pour garantir la qualite de mon service ? Comment puis-je encore 
gagner les points manquants de qualite de service sur mon 
service ? 

• Une demarche de prevoyance. Anticiper et rechercher comment 
eviter les pannes potentielles. 

• Un principe d’apprentissage continu par l’experience : savoir tirer 
les lemons du passe. Savoir reproduire les bons exemples. Savoir 
copier. 

Pour accomplir correctement sa mission, le processus de gestion des 
problemes a besoin de certains moyens sur lesquels il est recom- 
mande de ne pas trop negocier... Voici quelques recommandations 
qui devraient etre suivies pour asseoir la mission du processus de 
gestion des problemes. 

Fonctionnement 

Creer une fonction de gestionnaire des problemes, independante de 
celle de gestionnaire de la gestion des incidents, avec comme objec- 
tifs de minimiser les impacts des incidents dus a des erreurs dans 
l’infrastructure informatique et de faire diminuer l’occurrence des 
incidents lies a ces erreurs. 

| Mettre en place la separation hierarchique entre la gestion des inci- 
J. dents et la gestion des problemes. S’agissant de deux objectifs diffe- 
I rents (pouvant etre antagonistes), cela est necessaire pour permettre 
| l’analyse a froid des erreurs. Toutefois, la gestion des problemes doit 
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travailler de maniere etroite avec la gestion des incidents afin de 
recueillir aupres de la gestion des incidents les informations necessai- 
res a l’analyse des erreurs et fournir a la gestion des incidents des 
solutions de contournement pour des erreurs connues. 

Identifier des experts de reference afin de propager des bonnes prati- 
ques d’investigations et de diagnostic et de federer un partage de 
connaissance. 

Inclure les experts de niveau 2 et 3 dans la structure en charge de la 
gestion des problemes. Leur fixer formellement des objectifs mesura- 
bles sur les gains vises en qualite de service. 

Outillage 

Faciliter l’analyse de la base Incident pour la detection des problemes 
en optant pour un outil de gestion des incidents centralise, accessible 
aux experts de la gestion des problemes. 

Decider du format des donnees devant etre enregistrees dans les 
bases de problemes et d’erreurs connues. 

Mettre en place une base Problemes, dont la propriete est confiee a 
la gestion des problemes. Cela permettra de centraliser l’ensemble 
des donnees inherentes aux problemes ouverts, de les partager avec 
l’ensemble des autres processus voisins, et de responsabiliser la 
gestion des problemes sur l’entretien de ces donnees. 

Mettre en place une base Erreurs connues, dont la propriete est 
confiee a la gestion des problemes. Cela permettra de capitaliser 
l’ensemble des solutions trouvees suite aux recherches effectuees par 
la gestion des problemes, au profit de la gestion des incidents. 

En cas de choix d’outillage pour la gestion des problemes, choisir 
l’outil sur lequel il y a aura le moins possible de developpement 
specifique a realiser. Restreindre les specificites internes (elles 
doivent demeurer des exceptions). 

Procedure et modes operatoires 

Mettre en place une definition claire des roles et responsabilites entre 
les differents acteurs de la DSI sur le processus. » 

Mettre en place les procedures d’interventions du personnel d’assis- |> 
tance des problemes concernant le support a la gestion des incidents | 
et au traitement d’incidents majeurs. | 
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Mettre en place la procedure de fonctionnement entre le Centre de 
services et les equipes de la gestion des problemes. 

Mettre en place les passerelles de fonctionnement entre les processus 
de gestion des incidents et de gestion des problemes. 

Management 

Definir les objectifs mesurables attribues au personnel d’assistance 
des problemes. 

Definir, mettre en place et suivre un planning de formations sur la 
gestion des problemes, adapte en fonction des roles de chaque 
acteur du processus. 

Encourager les experts a communiquer en interne a la DSI sur les 
gains valides par la cloture des problemes et/ou des erreurs asso- 
ciees. 

Pilotage 

Mettre en place les indicateurs pertinents permettant de mettre en 
visibility la performance du processus pour l’amelioration de la 
qualite de service. Veiller a ne pas definir des indicateurs qui ne 
pourront pas etre mesures ou ne le pourront que tres difficilement 
(indicateur 100 % manuel par exemple). 

Organiser une revue de fonctionnement du processus par la mise en 
place de comite de pilotage ; ces comites de pilotage doivent impli- 
quer la direction. 




Chapitre 2 

Vue d’ ensemble du processus 


L’ECOSYSTEME DU PROCESSUS 

Cette partie a pour objectif defaire etat des principales rela- 
tions et interconnexions entre les autres processus de gestion 
des services et le processus de gestion des problemes. 

Nous apporterons quelques exemples concrets afin d’illustrer 
les principales interactions entre le processus de gestion des 
problemes et d’ autres processus. 

Nous apporterons des reponses aux questions suivantes : 

Quelles connexions entre la gestion des problemes et les pro- 
cessus de gestion de la capacite, de la disponibilite, des inci- 
dents, des changements, des configurations ? 

Comment le processus de gestion des problemes interagit-il 
avec ces autres processus ? 

Nous avons aborde le double aspect du processus de gestion des 
problemes, qui d’une part est reactif et d’autre part proactif. Ces deux 
sous-processus communiquent entre eux en continu et constituent le 
systeme relationnel recurrent et interne au processus de gestion des 
problemes. 

Ce systeme est egalement alimente par d’autres processus externes 
qui s’interconnectent avec le processus de gestion des problemes au 
profit d’une meilleure gestion des services informatiques. Les rela- 
tions entre les autres processus ITIL et la gestion des problemes sont 
nombreuses et le bon sens doit permettre de promouvoir celles qui 
ont tout interet a exister pour favoriser un bon fonctionnement. 
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Le systeme relationnel de la gestion des problemes, dans ces princi- 
paux elements d’interconnexion, pourrait etre represente par la 
figure 3.1. 



Figure 3-1 : Interconnexion de la gestion des problemes 

Le processus de gestion des problemes interagit avec les processus 

suivants. 

Gestion des incidents 

• En dormant des feedbacks sur la capitalisation au gestionnaire de 
l’incident pour aider a la resolution d’un incident. 

• En donnant des indications sur les changements necessaires pour 

corriger de fagon permanente les erreurs detectees sur l’infrastruc- 
ture du systeme d’information. 1 

• En aidant la gestion des incidents a determiner la priorite des inci- | 

dents qui lui sont adresses. ® 
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• En apportant un niveau d’expertise en cas d’escalade de la 
gestion des incidents (c’est une partie de la procedure d’escalade 
de la gestion des incidents). 

• En intervenant sur l’organisation d’une cellule d’incident majeur 
sur declenchement et alerte de la gestion des incidents. 

• En apportant des informations et des conseils sur la strategic de 
resolution des incidents sur un type d’application ou de service. 

• En mettant a disposition la documentation des solutions aux 
problemes et erreurs connues par l’intermediaire des bases de 
problemes et des erreurs connues. 

Gestion des configurations 

• En donnant des details sur les erreurs connues et la relation avec 
les elements de configurations concernes, leur criticite, et leur 
dependance. 

• En fournissant des donnees sur rhistorique d’elements de confi- 
guration issues des analyses. 

• En apportant des informations sur les fournisseurs externes, les 
contrats. 

Gestion des changements 

• En formalisant les demandes de changement visant a apporter des 
corrections structurelles des erreurs detectees dans le SI. 

• En se tenant informe par le processus de gestion des change- 
ments de la planification, de la realisation, et de la cloture des 
changements. 

• En participant au CAB (Change Advisory Board) afin de mettre en 
priorite haute ou en traitement urgent les demandes de change- 
ment, rattachees a la resolution de problemes majeurs. 

• En consultant la base des changements dans le cadre d’investiga- 
tions et de diagnostics sur les problemes. 

Gestion de la capacite 

• Dans le cadre d’analyse de tendance, de l’identification et du trai- 
tement de problemes en mode proactif. 
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• En analysant les rapports de type « capacity planning », le resultat 
de sondes permettant le monitoring de la performance du 
systeme ou le debit, afin de valider et d’instruire les recommanda- 
tions emises par la gestion de la capacite. 

Gestion de la disponibilite 

• En recherchant des solutions afin de repousser les limites du systeme 
pouvant provoquer des ruptures de disponibilite de services. 

• En etudiant les rapports statistiques de la disponibilite des servi- 
ces afin d’en degager des axes d’ameliorations. 

Les entrees/sorties du processus 

Cette partie a pour objectif de presenter les donnees d’entree 
et de sortie du processus de gestion des problemes. 

Nous decrirons ces entrees/sorties en distinguant les aspects 
reactifs et proactifs du processus. 

Nous apporterons des reponses aux questions suivantes : 

De quelles entrees a besoin le processus sous sa forme reac- 
tive et proactive pour s’ executer defagon efficace ? 

Quels sont les processus qui dispensent ces entrees au proces- 
sus de gestion des problemes ? 

II faut distinguer les entrees et sorties du processus selon que le 
processus est decline en mode reactif ou proactif. 

Elements d’entree de la gestion des problemes reactive 
Le but est de detailler les incidents, actions palliatives, et elements de 
configuration identifies (cela necessite des enregistrements precis et 
comprehensibles des incidents afin d’en identifier clairement et effi- 
cacement les causes) : 

• service affecte ; 

• application supportant le service ; 

• detail de Taction ayant permis de retablir le service ; 

• niveau de support et competence(s) pour acceder a Taction de | 

retablissement de service ; ° 
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• date et heure de detection ; 

• date et heure de declaration ; 

• date et heure de cloture ; 

• contexte de l’incident et historique de 1’evolution du et/ou des 
symptomes ; 

• code cause identifie lors de la gestion de l’incident ; 

• engagement SLA affecte. 

Elements d’entree de la gestion des problemes proactive 

Rapport de tendance (CMDB, Configuration Management DataBase) : 

• element de configuration (Cl, configuration item) modifie par 
application ; 

• Cl modifie par service ; 

• etc. 

Gestion de la capacite : 

• utilisation de l’unite centrale (CPU) ; 

• l’utilisation memoire ; 

• le pourcentage d’utilisation de CPU par type de transaction ; 

• les taux d’entrees/sorties (physique et memoire tampon) et 1’utili- 
sation des peripheriques ; 

• la longueur de la file d’attente (maximum, moyenne) ; 

• le nombre de transactions par seconde (maximum et moyenne) ; 

• le temps de reponse transactionnelle ; 

• etc. 

Gestion de la disponibilite : 

• cout tangible et intangible de la non-disponibilite ; 

• niveaux de services non respectes de fagon recurrente ; 

• etat des indisponibilites programmees ; 

| • frequence des indisponibilites par application, service, niveau 

8, d’impact ; 


etc. 
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Elements de sortie de la gestion des problemes reactive 
et proactive 

Generation des erreurs connues. 

Emission de demandes de changement (RFC) qui viennent alimenter 
le processus de gestion des changements. 

Mise a jour de l’enregistrement du probleme. 

Reponse sur la correspondance entre incidents et problemes/ erreurs 
connues qui viennent alimenter le processus de gestion des incidents. 
Information de synthese, rapport et tableau de bord d’indicateurs, 
revue des dossiers prioritaires, etc. 

Recommandations techniques pour securisation du S.I. 

Plan d’amelioration ou projet d’amelioration de la qualite de service. 
Plan de formation interne/externe. 

LeS ACTIVITES DU PROCESSUS 

Cette partie a pour objectif de presenter les activites opera- 
tionnelles du processus de gestion des problemes aussi bien 
reactive que proactive. 

Nous decrirons chacune des actions visees dans les activites 
devolues au processus de gestion des problemes. 

Nous apporterons des reponses aux questions suivantes : 

Quelle est la description en boite blanche du processus de 
gestion des problemes ? 

Quelles sont les activites intrinseques a chacune des etapes du 
processus de gestion des problemes (reactive ou proactive) ? 

Certaines activites du processus de gestion des problemes ressem- 
blent a celles du processus de gestion des incidents. 

Pour le processus reactif, il s’agit tout simplement d’identifier le 
probleme, de l’enregistrer, de lui attribuer une priorite, de pallier la 
cause, de memoriser ce que Ton fait, puis de rechercher une solution 
definitive, de memoriser cette demiere, de planifier et mettre en place 
cette solution definitive, et enfin de clore definitivement le probleme. » 
Cette partie reactive du processus de gestion des problemes se |> 
decompose en deux sous-processus appeles controle des problemes | 
et controle des erreurs. 
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Le controle des problemes comprend l’identification, l’enregistre- 
ment, la classification du probleme (type, priorite, etc.), la recherche 
de la cause (comprehension des raisons qui engendrent le symp- 
tome) et la mise en place d’une solution provisoire. La finalite est 
d’identifier la cause premiere (element de configuration par exem- 
ple) et de fournir au Centre de services des informations sur les solu- 
tions de contournement quand elles existent. Concernant les 
solutions de contournement, il faut preciser que la gestion des inci- 
dents en definit dans l’urgence (une ou plusieurs) et que la gestion 
des problemes les etudie et definit les meilleures d’entre elles. 

Le controle des erreurs englobe l’identification, l’enregistrement, 
1’evaluation (cout, delai), et la resolution de l’erreur (le medicament 
qui permettra d’amoindrir l’effet nefaste du symptome ou mieux 
encore de l’empecher de se reproduire). Le but est d’eradiquer des 
erreurs connues en emettant vers la gestion des changements une 
demande de changement (RFC) et en la suivant jusqu’a sa mise en 
place effective. Il s’agit done de resoudre les erreurs existantes sur le 
systeme d’information, et de les supprimer quand cela est possible et 
justifiable budgetairement. 

D’autres activites complementaires sont egalement a prendre en 
compte dans le cadre de l’execution reactive du processus. Il s’agit du 
support a la gestion des incidents et du traitement d’incidents majeurs, 
ainsi que des activites de pilotage telles que la surveillance et le suivi 
des problemes, ou encore la surveillance et le suivi des erreurs. 

Les activites de surveillance et de suivi des problemes et des erreurs 
sont des activites transversales a l’ensemble du processus de gestion 
des problemes, autrement dit le pilotage operationnel du processus. 
Pour le processus proactif, il va s’agir de prendre du recul et d’explo- 
rer toute information permettant de deduire la probability de proble- 
mes ou d’incidents sur le systeme d’information. 



Figure 3-3 : BoTte blanche de la gestion proactive des problemes 
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La prevention des problemes est la recherche effectuee pour la reso- 
lution anticipee des problemes ou des incidents susceptibles d’abais- 
ser la qualite de service a partir d’analyses de tendances, d’outils 
d’alertes proactives, qui indiquent le potentiel de panne du systeme 
d’information et en particulier des informations concernant le mate- 
riel, le logiciel, l’architecture, done les elements de configuration (Cl). 
La finalite est d’identifier et de resoudre les problemes avant que les 
incidents ne surviennent. 

L’analyse des tendances est un moyen, rarement utilise dans le 
domaine de l’informatique, mais pourtant redoutable pour (identifi- 
cation d’elements de configurations qui fragilisent (infrastructure 
(impact, risque de panne). Les sources d’informations sont, entre 
autres, les suivantes : 

• base d’incidents, de problemes et erreurs connues ; 

• outil de supervision de (infrastructure 

• informations externes (veille technologique) ; 

• utilisateurs (enquetes de satisfaction, groupe de travail, etc.). 

Deux types d’actions vont etre envisages selon la categorie : 

• identification d’erreurs (isolees) dans (infrastructure (transmise au 
controle des problemes et des erreurs pour correction) ; 

• identification de problemes plus generaux necessitant des actions 
de fond (et traitees dans (activite proactive d’initialisation 
d’actions preventives). 

Une autre activite complementaire est egalement a prendre en 
compte dans le cadre de (execution proactive du processus. II s’agit 
de la revue des problemes majeurs. 


(activite proactive de gestion des problemes est une entree du processus de 
gestion reactive des problemes. Tout probleme decouvert en proactif fait 
ensuite I’objet d’un passage dans les activites du controle des problemes et du 
controle des erreurs. 


Controle des problemes et controle des erreurs 

§ Cette partie a pour objectifde presenter les deux composan- 
| tes qui structurent la gestion reactive des problemes, appelees 

| controle des problemes et controle des erreurs. 
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Nous tacherons d’aborder dans le detail les tenants et abou- 
tissants de ces deux types de controles. 

Nous apporterons des reponses aux questions suivantes : 
Qu’est-ce que le controle des problemes ? 

Qu’est-ce que le controle des erreurs ? 

Quelles sont les preconisations pour un bon fonctionnement 
de ces deux types de controles ? 



Controle des erreurs 

Figure 3.4 : Controle des problemes et controle des erreurs 

Le controle des problemes, nous l’avons vu precedemment, a pour 
objectif d’identifier la cause premiere (element de configuration par 
exemple) et de fournir au Centre de services des informations sur les 
solutions de contournement quand elles existent. II s’agit de traiter le 
probleme de la fagon la plus efficace et productive possible. 

Le controle des erreurs a pour but d’eradiquer des erreurs connues 
en emettant vers la gestion des changements une demande de chan- 
gement (RFC ou Request For Change) et en la suivant jusqu’a sa mise 
en place effective sous le controle du processus de gestion des chan- 
gements. II s’agit d’un controle de la progression de la resolution du J 
probleme vers une elimination definitive de l’erreur detectee dans le |j> 
systeme. La mise en oeuvre est conditionnee par la faisabilite et le | 
retour sur investissement. “ 
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Les objectifs operationnels de ces deux controles sont done bien 
distincts. Dans la pratique, il est preferable de bien veiller a piloter 
ces deux objectifs dans une coherence rigoureuse de gestion. 

Le controle des problemes 

Le controle des problemes comporte une similarite evidente avec 
celle du processus de gestion des incidents. La difference tient dans 
le fait que l’objectif est de rechercher la cause premiere pour la traiter 
avec une solution de contournement (ou definitive si elle est facile- 
ment accessible a ce stade), contrairement au processus de gestion 
des incidents qui a pour but non pas de rechercher la cause des inci- 
dents, mais bien de retablir le service dans les plus brefs delais. 

Le processus de controle des problemes est dependant de la qualite 
du processus de gestion des incidents. La mise en place et la qualite 
du processus de gestion des incidents est une condition sine qua non 
a la mise en place du processus de gestion des problemes. Il ne faut 
done pas s’imaginer que seule l’expertise est necessaire pour mettre 
en vie un processus de controle des problemes. 

Lorsqu’un probleme est identifie par un incident ou un groupe d’inci- 
dents donne, alors toutes les informations inherentes a la gestion de 
l’incident ou de ces incidents doivent etre disponibles pour le 
controle des problemes. Les solutions de contournement mises en 
oeuvre par la gestion des incidents doivent etre enregistrees avec le 
probleme par le processus de controle des problemes. 

Le controle des problemes permet d’empecher la reapparition d’inci- 
dents rattaches aux problemes qui font l’objet d’un examen de 
controle dans le cadre de ce processus. 

A nouveau (nous n’insisterons certainement pas assez), e’est un 
processus qui necessite une approche particulierement rigoureuse et 
pragma tique de gestion. L’effort de gestion necessaire sur le controle 
des problemes ne doit pas etre sous-estime. Les experts sont norma- 
lement reconnus pour leur connaissance pointue dans un domaine, 
une competence, une technologie donnee, et e’est justement la ou le 
bat blesse : etant generalement des specialistes, ils sont sollicites par 
| tous dans l’organisation. Leur emploi du temps est bien souvent un 
| vrai gruyere qui ne leur appartient pas vraiment et dans lequel ils ont 
I a coeur de mettre a profit leur connaissance sur les sujets qui attirent 
| la mise en pratique de leur competence rare. Le degre de gestion 



78 Ameliorer la qualite des services 


necessaire a un bon fonctionnement du controle des problemes est 
relativement important et s’apparente a de la gestion de projets. 

La planification des taches et le suivi des echeances de chacune des 
actions jouent un role primordial dans la reussite du processus de 
controle des problemes. Cette mise en pratique peut durer des semaines. 

Les experts ont bien souvent l’ame de veritables chercheurs. Ils ont done 
besoin d’un cadre, d’objectifs precis, de delais, de coordination plus que 
n’importe quelle autre ressource pour leur permettre de conserver la 
capacite a prendre du recul et surtout a reevaluer leur priorite. 

Ce besoin de gestion est a implementer dans le cadre du processus 
de controle des problemes par la mise en place d’une gouvernance 
claire et transparente des regies du jeu qui vont permettre de s’assu- 
rer que les experts utilisent leur temps precieux pour faire de la 
recherche sur les problemes les plus importants pour l’entreprise. 

Dans la projection precedente des activites du processus de controle 
des problemes, il est distingue deux instances de travail pour federer 
les efforts de soutien a apporter dans le cadre de la gestion des 
problemes : le comite de suivi des problemes et le groupe d’interven- 
tion d’experts. 

Le controle des problemes devrait etre realise en equipe, afin que les 
decisions issues de la revue des priorites soient prises de fafon colle- 
giale. De plus, ce travail d’equipe peut etre profitable pour la construc- 
tion d’une synergie, pour le partage des enjeux entre tous les acteurs et 
ainsi eviter les cloisonnements entre competences d’expertises. 

Veillez bien a systematiquement donner la priorite la plus forte au 
probleme qui occasionne le plus de dysfonctionnements sur l’acti- 
vite. Contrairement a la gestion des incidents qui a pour objectif de 
traiter tous les incidents dans les meilleurs delais et dans le respect 
des engagements de services, le but du controle des problemes n’est 
pas de traiter tous les problemes ! C’est le piege dans lequel il ne faut 
surtout pas tomber. 

Le controle des problemes sous-entend d’identifier et d’enregistrer 
tous les problemes (tragabilite). C’est une des cles de la reussite pour 
identifier les problemes les plus importants pour l’entreprise afin de 
mobiliser les experts sur le traitement de ces derniers, et uniquement J 
ceux-la. Le delai de traitement d’un probleme, dependant essentielle- 
ment de sa complexity, n’est pas un indicateur de la performance, ni | 
des acteurs en charge de l’expertise, ni du processus en tant que tel. | 
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Le contrdle des erreurs 

Le controle des erreurs est la composante particuliere du processus 
de gestion des problemes qui le differencie reellement de celui de la 
gestion des incidents. Cette distinction tient dans le fait que l’objectif 
est d’eradiquer definitivement l’apparition des incidents associes a 
l’erreur identifiee. Le controle des erreurs permet par ailleurs l’entre- 
tien d’une vraie bibliotheque d’informations recensant les moyens 
mis en oeuvre pour traiter les causes de non-qualite de service (la 
base des erreurs connues). 

Le processus de controle des erreurs est tres dependant de la qualite 
du processus de controle des problemes ainsi que de la gestion des 
changements. Sans un processus de gestion des changements de 
qualite, le processus de gestion des problemes echouera lors des 
activites qui devront s’executer dans le cadre de la mise en oeuvre 
des solutions definitives, etant donne qu’un des elements de sorties 
possible de ce processus est une RFC (Request For Change, ou 
demande de changement). 

Le controle des erreurs permet d’annuler definitivement la cause 
premiere a l’origine de l’apparition du probleme traite. C’est egale- 
ment un processus qui necessite une approche particulierement 
rigoureuse et pragmatique de gestion. 

La gestion sur le controle des erreurs doit etre scrupuleusement mise 
en place afin de permettre de decouvrir les meilleures solutions, 
c’est-a-dire celles qui vont repondre a l’objectif de traiter definitive- 
ment la cause premiere identifiee. Ce besoin de gestion est usuelle- 
ment pris en compte dans le cadre d’une meme instance de pilotage 
integrant egalement le controle des problemes. II faut savoir que le 
processus de controle des erreurs demande du temps, et represente 
done un investissement financier. 

D ’autre part, le processus de controle des erreurs est le point de 
contact privilegie avec les environnements de developpement des 
services. II represente une cle de voute incontournable entre les envi- 
ronnements de production et de developpement et leur permet 
d’echanger des informations sur les erreurs decouvertes soit dans 
l’un, soit dans l’autre. 



Ameliorer la qualite des services 


Gestion 
de la 
capacite 


'““l 


incidents 

I 


ni 




r 


Detection des 
problemes 

I 

Enregistrement 
du probleme 
\ 

Categorisation 
du probleme 

I 

Priorisation 
du probleme 

Assignation 
du probleme -* 

Investigation 
du probleme 
\ 

Cause 
trouvee et 
solution provisoire 
trouvee ? 


I-7 


observation 

* 

Impact diminue ? 

T 


Controle des erreurs 


Figure 3-5 : Workflow du controle des problemes 
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Bonne pratique a retenir 

La gestion des problemes est un processus qui necessite la mise en 
| oeuvre de moyens non negligeables (outils, ressources d’expertise). 
I C’est un processus relativement couteux et done une raison supple- 
| mentaire pour decider des problemes a traiter selon leur impact sur 
| la qualite de service. L’organisation peut decider de ne pas traiter les 
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problemes dont les incidents se resolvent rapidement, et pour 
lesquels l’impact subi par l’utilisateur et l’entreprise est faible. 

Ceci etant, il reste neanmoins structurant d’avoir enregistre ces 
problemes dans la base des problemes et/ou des erreurs connues en 
y renseignant les elements d’informations factuels et necessaires qui 
donnent du sens a la decision prise. 


© 



Chapitre 3 

Gestion reactive des problemes 


LES 8 ETAPES DU PROCESSUS REACTIF 

Cette partie a pour objectifde detailler le fonctionnement du 
processus de gestion reactive des problemes. 

Nous aborderons, pour chacune des activites, leurs objectifs, 
leurs enjeux, les livrables associes et les bonnes pratiques a 
retenir. Nous tacherons egalement de presenter un panel 
d’outils pouvant etre mis en oeuvre pour la gestion et la reso- 
lution reactive des problemes. 

Nous apporterons des reponses aux questions suivantes : 
Comment attribuer un niveau de priorite a un probleme ? 

A partir de quels elements ? 

Comment traiter un probleme ? 

Quelles methodes mettre en oeuvre pour en decouvrir la 
cause et resoudre le probleme ? 

L’identification et l’enregistrement des problemes 

L’identification du probleme est importante ; c’est une etape determi- 
nante pour la suite des operations. On peut retenir qu’« un probleme 
sans solution est un probleme mal pose » (Albert Einstein), 
^identification s’effectue au moyen de : 

• La comparaison des incidents pendant la phase de support initial 
et de classement des incidents qui n’a pas ete concluante ou qui 
n’a pas eu lieu. 
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• La prise en compte d’alertes concernant la non-applicabilite des 
solutions de contournement possible. 

• L’analyse de la base Incident. 

• La detection de situation constatee par des acteurs des processus 
de gestion de la capacite, de la disponibilite ou autres. 



Objectif de I'activite : detecter et 


is les problemes dans une base unique 


A I'enregistrement le dossier probleme contient notamment 
les informations suivantes : 

- Indice du probleme : numero du probleme 

- Date et heure d'ouverture du probleme 

- Description du probleme 

- Nombre d'indicents rattaches au probleme 

- Evaluation de la reproductibilite : faible/moyenne/forte 
-etc. 


Figure 4-1 : Enregistrement d’un probleme 


Les criteres identifies pour l’ouverture d’un probleme dans le cadre 

de la gestion reactive des problemes sont les suivants : 

1 . incident majeur ; 

2. degradation d’un niveau de services. (Quelques exemples : non 
respect recurrent d’un ou plusieurs memes niveaux de services, 
erosion a petit feu du niveau de services) ; 

3. incident a cout prohibitif (exemple : incident en cours depuis six 
mois) ; 

J 

4. incident en cours, sans solution de contournement trouvee ; 1 

5. incident recurrent, c’est-a-dire : | 

• incident dont la cause initiale est similaire ; ° 
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• incident dont la solution de contournement est similaire ; 

• incident dont les symptomes sont similaires ; 

• nombre d’incidents eleve sur une application voire un domaine 
metier (forte probabilite de correlation). 

L’analyse structurelle de l’infrastructure informatique, les rapports 
d’experts sur l’analyse des incidents et des reunions avec les utilisateurs 
des services informatiques peuvent egalement permettre d’identifier des 
problemes dans le cadre de la gestion proactive des problemes. 

Un probleme ouvert et enregistre dans la base des Problemes doit 
comporter un certain nombre d’informations qui vont constituer sa 
carte d’identite. La liste de ces elements figure en annexe 1. 

A l’ouverture d’un dossier probleme, les informations suivantes 
doivent etre egalement enregistrees : le libelle court de chacun des 
incidents rattaches au dossier probleme et le lien vers la base Inci- 
dent pour chacun des incidents rattaches au dossier Probleme. 

II est important d’enregistrer tous les problemes, memes ceux qui a 
priori ou de fagon certaine sont sans impact et sans risque sur la 
qualite de service. L’enregistrement des problemes est un recense- 
ment pertinent mais aussi global de l’ensemble des problemes detec- 
tes sur l’infrastructure du systeme d’information. 

Vous trouverez ci-dessous un exemple de fiche signaletique syntheti- 
que pour la representation d’un probleme dans l’objectif d’un rapport. 
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II est interessant de definir un compteur d’incidents associes a un probleme et | 

de fixer des seuils de depassement de ce compteur afin d’alerter I 1 

automatiquement, en cas de depassement du seuil. | 

© 
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Le classement des problemes 



problemes 



Objectif de I'activite : determiner la priorite de traitement 


La priorite se determine par : 

- le chiffrage du surcout d'exploitation en (jour/homme), 

- le niveau d'impact QoS (fort, moyen, faible, sans), 

- le nombre de points de QoS perdus, 

- I'urgence de traitement. 

A formaliser a I'aide d'une grille devaluation de I'impact 
QoS. 

La priolriete du probleme doit faire I'objet d'une validation 
collegiale de chaque partie prenante. 

Enjeu : tous « courir la meme course ». 


Figure 4-2 : Fiche memo du classement des problemes 


Apres ouverture du dossier Probleme, celui-ci doit etre qualifie afin 
de definir la repartition des efforts qu’il est necessaire d’engager sur 
les dossiers Problemes a traiter. Cette action est effectuee dans le 
cadre de I’activite de classement du processus de gestion des proble- 
mes. 

Comme pour les incidents, la hierarchisation des problemes en vue 
de leur traitement se base sur l’association de deux facteurs cles : 
I’impact et I’urgence. On peut ainsi calculer « la valeur » d’un 
probleme, et ordonnancer sa resolution. Ce critere est egalement 
necessaire afin de valider si un probleme doit etre ou non traite, et 
s’il est economiquement justifiable qu’il fasse I’objet d’une demande 
de changement. Ce raisonnement va permettre d’eviter de se concen- 
trer sur un probleme qui prend en compte de nombreux incidents 
„ n’ayant qu’un impact reduit sur l’entreprise au detriment d’un 
| probleme moins mediatise mais plus couteux. 

| Les criteres de classement d’un probleme sont relativement similaires 
| a ceux mis en oeuvre dans l’etape de classification des incidents : 
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• Categorie : groupe de domaines techniques (caique sur l’organisa- 
tion). 

• Impact : effet sur les activites metiers. II s’agit du niveau d’impact 
sur la qualite de service en situation de dysfonctionnement. 

• Urgence : delai maximum que peut supporter la resolution d’un 
probleme. II s’agit du risque evalue de reproductibilite par rapport 
a la disponibilite d’une solution de contournement. 

• Priorite : ordre de traitement du probleme par rapport a la liste 
globale. 

L’identification et l’enregistrement sont necessairement suivis d’une 
phase d’evaluation de l’impact du probleme et done de caracterisa- 
tion des effets negatifs constates sur l’activite. 

Pour rappel, concernant la notion d’impact : il s’agit ni plus ni moins 
des consequences et des repercussions negatives d’un incident ou 
d’un probleme sur les activites de l’entreprise. La gestion des proble- 
mes a pour objectif de minimiser ces impacts en apportant une 
correction structurelle sur le systeme d’information. L’une des diffi- 
culty reside dans le fait qu’il s’agit d’une classification a un instant 
donne (elle peut evoluer dans le temps). 

Un exemple de matrice d’evaluation des impacts qui permet de 
rassembler l’ensemble des informations inherentes a un impact figure 
dans le tableau suivant. 
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Matrice d evaluation des impacts de services metiers 


Impact services 
metiers 

Mode operatoire 

o 

Intitule du (ou des) 
service(s) affecte(s) 

Intitule du contrat de service metiers. 

E 

Description de 

Description des ecarts par rapport au(x) service(s) metier(s) 

■n 

I’impact client 

convenu(s) au contrat de service. 



Evaluation de I’impact sur le chiffre d’affaires et/ou 

Sj 

Impact sur I’activite 

description de I’impact image. 

ra 


Evaluation de I’impact sur les couts de support. 

=j 



Mode operatoire de calcul des points 

8 



de QoS gagnes : 

1 



Soit un probleme dont l'(es) Incident(s) 

-of 



associe(s) touchant un indicateur de 

c 



niveaux de services metiers. Nous 

8 



appellerons la valeur de cet indicateur 

(0 



la valeur A. 

8 



1 . Faire une simulation de I’indicateur 

| 

Nombre de points de 
QoS perdus 

Evaluation du % de 
points de SLA 
perdus a cause du 
probleme 

en retirant du calcul les durees des 
incidents rattaches au probleme 
donne. Appelons cette nouvelle valeur 
de I’indicateur la valeur B. 




2. Cette valeur B correspond a la 

£ 



valeur qu'aurait eu I’indicateur si les 




incidents rattaches a ce probleme 

Q. 



etaient eradiques (done dans le cas ou 

2 



le probleme ferait I’objet d’une solution 

8 



concluante provisoire ou definitive). 

8 



3. Le nombre de points de QoS perdus 

i£ 



suite au probleme est egal a la 
valeur B - la valeur A. 


II est clair que 1’evolution de l’impact est egalement conditionnee au 
nombre d’incidents associes au probleme en cours de resolution. Ce 
nombre peut evoluer au fil du temps, devenir preoccupant et peut 
necessiter d’augmenter le niveau de priorite pour que le probleme 
soit resolu plus rapidement. 

En resume, la qualification des impacts sur le ou les services metiers 
d’un dossier Probleme doit inclure les elements suivants : 

| • l’identification des services metiers affectes ; 

I • 1’evaluation de l’impact sur l’activite, incluant le surcout d’exploitation 
| du service et la perte financiere occasionnee sur le chiffre d’affaires ; 
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• 1’evaluation de l’impact sur la QoS (ou risque d’impact) en preci- 
sant le nombre de points de QoS perdus. 

II est de bon usage de prendre en consideration que le niveau 
d’impact QoS qualifie a l’initial peut croitre et done faire l’objet d’une 
reevaluation a la hausse (exemple : impact QoS Faible vers Moyen 
ou vers Fort). Meme si ce niveau d’impact peut decroTtre dans les 
faits, il est conseille de ne pas declasser 1’evaluation de l’impact QoS 
en correspondance. Un probleme a fort impact peut vite tomber dans 
l’oubli s’il est declasse a mesure que l’impact devient moindre. 

L’indice de priorite 

C’est principalement une combinaison de l’impact et de l’urgence, 
mais aussi de risque de defaillance et de disponibilite des ressources. 
L’urgence doit permettre de donner une indication sur le delai selon 
lequel il serait opportun de traiter. L’impact doit permettre de donner 
une indication sur le degre d’impact engendre. 

La priorite doit permettre de definir un ordre relatif de traitement du 
dossier (idem sur la gestion des changements, des incidents). L’indice 
de priorite est en quelque sorte l’ordonnateur qui permet de mettre 
en evidence les preoccupations par ordre d’importance. 

Impact = la taille de la bombe Ur 9 ence = la taille de la mache 



Figure 4-3 : Niveau de priorite 

La priorite est fixee a un instant donne par rapport a 1’evaluation d’un 
impact et d’une urgence. Elle peut done evoluer dans le temps. La 
modification de la priorite est a manipuler avec bon sens et en ayant 
systematiquement a l’esprit les activites metiers, les enjeux pour J 
l’entreprise (ne pas appliquer systematiquement a la lettre ce que J- 
donne la combinaison impact et urgence). Il faut neanmoins retenir | 
que tous les problemes ont un degre d’importance (c’est pour cela ° 
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qu’il n’y a pas d’indice « nul »). Par definition, tous les problemes font 
et feront l’objet d’un traitement. 

Ne vous y trompez pas : definir une priorite n’a pas pour vocation de 
faire disparaitre certains problemes consideres comme peu impor- 
tants. Tous les problemes doivent faire l’objet d’un traitement. Deci- 
der qu’un probleme ne fera pas l’objet d’une resolution au regard 
d’un risque d’impact extremement minime sur la qualite de service 
fait egalement partie du traitement. 

Cela etant, tous les problemes ne peuvent etre classes en categorie 
de priorite PI pour autant ! Souvenez-vous de la loi de Pareto : 20 % 
des problemes representent 80 % des preoccupations. 

Vous trouverez ci-dessous un exemple de matrice de classement par 
priorite des problemes. 
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Matrice devaluation du niveau d’impact QoS 

Impact QoS 

Fort 

Moyen 

Faible 

Sans 

Niveau d’impact 

Impact SLA 

Le probleme ou 
I’anomalie de 
developpement 
provoque une 
perte de service 
sur I’un des 
30 services de 
categorie 1 . 

Ou 

Le probleme 
contribue a 
100 % de la 
perte de SLA 
autorisee surun 
service de 
categorie 2. 

Le probleme ou 
I’anomalie de 
developpement 
contribue a au 
moins 50 % de 
la perte de SLA 
autorisee sur 
un service de 
categorie 2. 

Le probleme ou 
I’anomalie de 
developpement 
contribue de 
0 % a 50 % de 
la perte de SLA 
autorisee surun 
service de 
categorie 2. 

Le probleme ou 
I’anomalie de 
developpement 
n’affecte pas le 
SLA autorise sur 
un service de 
categorie 2. 

Impact 

Exploitable 

NON 

OUI 

OUI 

OUI 

Niveau de priorite 

Priorite 

PI 

P2 

P3 

P3 

Note : pour les 
anomalies et les 
problemes, 
I’impact QoS 
Fort est 
bloquant pour 
les mises en 
place (MEP) 
Projets 

Note : pour les 
anomalies et 
les problemes, 
I’impact QoS 
Moyen est non 
bloquant pour 
les mises en 
place (MEP) 
Projets 

Note : pour les 
anomalies et 
les problemes, 
I’impact QoS 
Faible est non 
bloquant pour 
les mises en 
place (MEP) 
Projets 

Note : pour les 
anomalies et les 
problemes, 
I’impact QoS 
Faible est non 
bloquant pour les 
mises en place 
(MEP) Projets 

Solution de 
contournement 

Implementation 
d’une solution de 
contournement 

Cible a 24 h 

Cible a 48 h 

Cible a 5 jours 
ouvres 

NON 

1 

1 

o 

(/> 

Implementation 
d’une solution 
definitive 
conditionnee par 
la mise en place 
(MEP) d’un 
correctif 
d’anomalie de 
developpement 

25 jours ouvres 

45 jours ouvres 

90 jours ouvres 

90 jours ouvres 

Fil de I’eau 

Lotissement 
recommande 
(notamment 
pour les mises 
en place (MEP) 
de correctif 
d’anomalie) 

Lotissement 
recommande 
(notamment 
pour les MEP 
de correctif 
d’anomalie) 

Lotissement 
recommande/ 
Versions (pour 
les MEP de 
correctif 
d’anomalie) 


53 

1 
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L’investigation et le diagnostic des problemes 





L'investigation doit permettre de consolider les 
elements suivants : 

1. I'analyse de la cause du probleme 

2. la proposition de solution provisoire (palliatif) -> 
optionnel si la solution definitive peut etre mise 
en oeuvre rapidement. 

Important : les logs ou traces doivent obligatoirement 
etre ajoutees a I'analyse. 

Le groupe d'intervention des experts (le GIE) est le 
groupe d'experts necessaires pour investiguer sur le 
probleme. II doit de fajon prefdrentielle etre pilot# par 
un expert referent, c'est-a-dire I'expert qui a le plus 
d'experience sur la problematique donnee. 


Figure 4-4 : Fiche memo de l’investigation et diagnostics des problemes 


Si un jour vous entendez votre directeur informatique vous dire 
« Mais combien de temps faudra-t-il encore attendre pour que la 
cause soit identifiee ? », dites-vous que cette remarque revele une 
realite : vous etes en mission d’investigation et de diagnostic. Cette 
activite demande un temps incompressible. D’une fagon naturelle, 
lorsqu’un probleme arrive, nous sommes habituellement tentes de 
nous concentrer sur le traitement des symptomes et non des causes a 
l’origine de son apparition. Sur ce point, l’activite d’investigation et 
de diagnostic effectuee dans le cadre du processus de gestion des 
problemes est differente de l’activite du meme nom. Elle traite : 

• les symptomes apparents ; 

• la cause a l’origine de l’apparition des symptomes. 

| Lorsque Ton enquete sur un probleme, il s’agit done de decouvrir 
l’element du Cl (configuration item) defaillant et a l’origine de la 
I survenance du ou des incidents rattaches au probleme ouvert. Une 
| fois la cause premiere mise en lumiere, la solution provisoire permet- 
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tant de contourner cette cause peut alors etre identifiee et mise en 
oeuvre. Cette activite necessite la mobilisation d’experts et demande 
du temps, de l’organisation et de la methode. Cette etape d’investiga- 
tion est un prerequis pour reussir a mettre en oeuvre les actions qui 
vont permettre de decouvrir : 

• Ce qui a reellement provoque le probleme et l’apparition des inci- 
dents associes. 

• Ce qui permet d’expliquer la raison pour laquelle le probleme se 
produit. 

• Ce qui peut etre fait pour empecher le probleme de se produire a 
nouveau. 

C’est une approche de type root cause analysis (analyse de cause 
racine). Durant ces investigations, le personnel de la gestion des 
problemes doit etudier les solutions de contournement concernant 
les incidents rattaches aux problemes analyses afin d’identifier la 
meilleure solution a appliquer en cas de reproduction de l’incident. 

Le travail de mise a jour et d’entretien de ces solutions de contourne- 
ment fait egalement partie integrante des investigations sur le 
probleme. 

En plus d’etre a la recherche de la cause premiere et du moyen de 
contourner cette cause, l’activite d’investigations et de diagnostic du 
processus gestion des problemes vient en support a celle de controle 
des incidents. 

Quelques bonnes pratiques a retenir 

La categorisation des problemes doit utiliser la definition de la cate- 
gorisation des incidents. 

Dans le cas ou la cause sous-jacente du probleme ne concerne pas 
une erreur de l’infrastructure technique du systeme d’information a 
proprement parler, mais plutot : 

• une procedure erronee ; 

• une procedure mal appliquee ; 

• un manque de formation des utilisateurs ; 

• une erreur d’administration, de supervision ; 1 

• une pratique non recommandee sur les environnements de | 

production faite a l’encontre des regies en vigueur, ® 
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la gestion des problemes doit : 

• Tracer cette cause dans la base des erreurs connues. 

• Creer un Cl factice. 

• Enregistrer l’erreur connue avec le Cl factice associe en tant que 
cause sous-jacente identifiee. 

• Faire passer le probleme en erreur connue. 

• Tracer la solution preconisee. 

Dans l’ordre, quelques exemples par rapport a la liste precedente : 

• mise a jour de la procedure ; 

• complement de la procedure avec des controles specifiques/ 
formation des supports en charge de l’application de la proce- 
dure/validation de la procedure par les supports concernes par 
son application ; 

• organisation de sessions de formation aupres des utilisateurs ; 

• developpement de solutions pour l’amelioration des moyens 
d’administration, de supervision/formation des supports en 
charge de l’administration, de la supervision ; 

• preconisation de moyens de controle et/ou securite supplemen- 
taires. 

Toutes les documentations sur l’utilisation et le fonctionnement des 
produits doivent etre disponibles pour l’investigation et le diagnostic 
des problemes ouverts (comme pour les incidents d’ailleurs). Elies 
devraient etre disponible dans un referentiel documentaire et 
comprendre la documentation a jour sur : 

• les parametrages applicatifs en production ; 

• les specifications d’automatisation ou de supervision des evene- 
ments ; 

• les scripts et traitements « faits maison » permettant d’operer le 
diagnostic, le controle ou le check-up d’un systeme ; 

• l’architecture reseau ; 

• l’architecture applicative ; 

| • l’exploitation. 

| Les informations concernant les changements recents doivent etre 
| disponibles pour l’investigation des problemes. Retenez que 80 % 
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des incidents sont lies a des changements. II vaut mieux s’etre inte- 
resse de pres au changement mis en oeuvre sur une periode en 
correspondance avec les incidents rattaches au probleme. Cette piste 
mene bien souvent a la cause sous-jacente du probleme. 

Enfin, de nombreuses methodes d’investigation, de diagnostic et de 
resolution des problemes viennent en complement de la connais- 
sance du personnel de la gestion des problemes. Ces methodes sont 
une aide non negligeable pour structurer la strategic d’investigation. 

II s’agit des methodes appelees : 

• Kepner & Tregoe ; 

• Diagramme d’Ishikawa ; 

• Les 5 pourquoi (ou 5 whys) ; 

• Six Sigma ; 

• Brainstorming ; 

• Methode 8D (Huit Disciplines) ; 

• Diagramme de Pareto. 

Nous vous aurons beaucoup parle de methode jusqu’a maintenant et 
ce n’est pas termine. La methode est une fondation dont a besoin 
l’action pour etre efficace dans Tatteinte du resultat voulu. 

Le diagramme d’Ishikawa ou la methode des 5 M 

La methode des 5 M s’applique a la recherche de causes dans le 
cadre des investigations de gestion des problemes. 

La methode des 5 M appelee encore diagramme d’Ishikawa ou 
diagramme en arete de poisson ou encore diagramme de cause a 
effet est un mode d’analyse systemique permettant d’etablir un 
diagnostic evolutif dans l’objectif d’un resultat attendu ou encore 
selon un resultat atteint. 

Cette methode a fait ses preuves (elle est utilisee dans les entreprises 
depuis une trentaine d’annees en France) et, bien que demandant un 
certain temps, elle permet d’obtenir des resultats concrets en matiere 
de diagnostic de problemes. Concretement, ce diagramme permet de s 
visualiser et d’analyser le rapport entre un probleme (l’effet) et toutes | 
ses causes possibles. & 

L’utilisation de cette methode presente des avantages interessants : “ 


Causes de non-QoS Causes de non-QoS 

(Matiere) (Main-d'ceuvre) 
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Causes de non-QoS Causes de non-QoS Causes de non-QoS 
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• Elle permet de classer les causes liees a un probleme pose. 

• Elle permet de faire participer chaque membre pertinent d’une 
equipe d’analyse et de federer leur savoir sur une meme cible 
visee. 

• Elle permet de limiter l’oubli de causes par le biais d’un travail en 
brainstorming. 

• Elle permet de fournir des elements pertinents pour l’etude des 
solutions provisoires (permettant de contourner le probleme) et 
definitives (permettant d’eradiquer completement la cause du 
probleme). 

Ce type de travail se prete completement a un groupe d’intervention 
d’experts qui souhaite adresser les investigations et le diagnostic d’un 
probleme. II ne s’agit pas d’operer en solo (meme pour le meilleur 
des experts). Ce diagramme est elabore en plusieurs etapes. Voici un 
exemple de demarche a suivre : 

• Decrire clairement le probleme. II s’agit de puiser dans les infor- 
mations formalisees suite aux phases precedentes du processus 
de gestion des problemes. 

• Dans le cadre d’un brainstorming avec l’ensemble des experts 
necessaires, determiner les causes principales participant a l’effet 
de non qualite de service selon les 5 categories suivantes : Main- 
d’oeuvre, Matiere, Materiel, Methode, Milieu. 

Durant le brainstorming, formuler le probleme de telle sorte de pren- 
dre le contre-pied de sa representation majoritaire et susciter des 
conflits cognitifs. En ce sens, ne pas hesiter a mettre en lumiere un 
resultat d’experience qui ne semble pas logique, ou qui entre en 
opposition pertinente avec ceux deja etablis. Etre a l’affut et relever 
des paradoxes, des options differentes, des faits qui etonnent ou qui 
impliquent fortement. 

• Inscrire chacune des causes principales evoquees dans le sque- 

lette du diagramme selon la categorie associee. Ces causes princi- 
pales (ou causes initiales) deviennent alors les noms des branches 
du diagramme. s 

• En posant systematiquement la question suivante « mais pourquoi J- 
cette cause produit-elle cet effet ?», completer les branches secon- | 
daires pour chaque categorie. Cette question permet d’enrichir le ° 
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diagramme en recherchant la cause racine ( root cause) pour 
chaque cause principale et sur chaque categorie. 

• Pousser l’exercice jusqu’a creer des branches tertiaires sur le 
diagramme si necessaire. 

• Identifier avec le groupe les causes principales peu probables 
qu’il est possible d’eliminer (la reflexion peut etre instruite par 
analyse Pareto). 

• Hierarchiser avec le groupe la probability de chacune de ces 
causes. 

• Pousser le groupe a proposer les actions a mettre en oeuvre et 
permettant d’agir sur la ou les causes identifiees pour corriger 
provisoirement ou definitivement cette cause. 

Resolution de Probleme 8D (Huit Disciplines) 

II s’agit d’une approche de resolution de probleme et de traitement 
des causes sous-jacentes (ou causes racines). Convaincu que l’equipe 
est supposee etre plus pertinente et bien meilleure que la somme des 
qualites de chacun des individus qui la composent, cette methode 
repose sur 8 disciplines, mettant en avant le travail d’equipe et la 
synergie des savoirs. 

Cette methode est egalement connue sous les noms de TOPS 8D, 
GLOBAL 8D, ou encore FORD 8D. 

Pour la petite histoire, le gouvernement des Etats-Unis a utilise pour 
la premiere fois une methode de type 8D durant la Seconde Guerre 
mondiale. Cette methode a ete definie sous la norme 1520 (systeme 
d’action corrective et de disposition pour materiel non conforme). 
Ford Company a documents pour la premiere fois la methode 8D en 
1987 a la demande de la direction generale de la division moteur du 
constructeur d’automobiles, pour premunir l’entreprise concernant 
des dysfonctionnements qui se reproduisaient annee apres annee. 
Notre processus de gestion des problemes ITIL ressemble pour beau- 
coup a cette approche. La methodologie de recherche de la cause 
issue de cette methode est un point d’ancrage interessant, dont il est 
egalement conseille de s’inspirer. 

I 
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Le « D4 » correspond aux actions pouvant etre engagees dans le 
cadre de l’activite d’investigation et de diagnostic de notre processus 
de gestion des problemes selon les bonnes pratiques ITIL. 

Dans la meme logique que le diagramme de causes a effet d’lshi- 
kawa, le principe consiste a identifier toutes les causes potentielles 
pouvant expliquer l’apparition du probleme, et par la suite tester et 
verifier chaque cause par rapport a la description du probleme et a 
toutes ses donnees. C’est un vrai travail d’enquete dont la finalite 
attendue est de decouvrir la cause sous-jacente d’evenement : le 
systeme qui a permis aux problemes de se produire (le coupable). 
Mais aussi la cause sous-jacente d’echappement : le systeme qui a 
laisse le probleme s’echapper sans detection (le complice). 


Recherche de cause par la methode de Kepner &Tregoe 
Le referentiel des bonnes pratiques ITIL decrit les etapes de la 
methode d’analyse de la root cause (cause racine) appelee Kepner J 
& Tregoe, mais il n’apporte pas assez d’informations sur la J- 
maniere d’utiliser cette methode dans le cadre de la gestion des | 
problemes. ° 
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Aussi simple que cela puisse paraitre, encore aujourd’hui, beaucoup 
de techniciens, d’ingenieurs, ou de responsables techniques ne 
suivent pas de methode de resolution de probleme bien precise ou 
structuree. A la place, ils s’en remettent frequemment (et sans en 
avoir pris reellement conscience) aux idees precongues, a leur intui- 
tion, a un systeme de pensee unique : « Tout le monde pense qu’il 
serait bien d’ explorer d’abord cette piste. » 

Or tout probleme a besoin d’un plan bien etabli pour prendre la 
bonne decision et mettre en marche la bonne strategic de resolution 
du probleme. Ce plan depend de la faculte a savoir poser le 
probleme. La denomination actuelle de la methode est Problem 
Solving and Decision Making de Kepner & Tregoe (PSDM). 

Le PDSM de Kepner & Tregoe comporte plusieurs principes similai- 
res ou complementaires a l’activite « investigation et diagnostic >• du 
processus de gestion des problemes selon le referentiel ITIL. En 
resume, il s’agit d’analyser le probleme. Dans la methode de Kepner 
& Tregoe, l’Analyse du Probleme (AP) permet d’identifier les causes 
entrainant la situation problematique vers une augmentation ou une 
diminution de ces effets. 

Le processus d’analyse se divise en 5 etapes : 

• Definir le probleme. 

• Decrire le probleme. 

• Etablir les causes potentielles. 

• Tester la cause la plus probable. 

• Verifier la vraie cause. 

Cette phase d’analyse du probleme (illustree sur le schema) deter- 
mine l’orientation que vous allez prendre pour resoudre le probleme. 


I 



3 


e 


Figure 4-7 : Analyse des problemes de Kepner & Tregoe 
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Prendre une mauvaise orientation peut avoir pour consequence de 
rendre la resolution du probleme bien plus difficile qu’elle ne l’aurait 
ete avec une strategic de resolution. II s’agit la encore d’un travail 
d’equipe (vous l’aviez compris, la gestion des problemes necessite le 
groupement d’intervention d’experts, done un travail en equipe). 

Comme sur un champ de bataille, le probleme se cree a cause d’une 
situation qui nous a echappe, cette situation est l’ennemi qu’il faut 
vaincre. Plus on arrive a cibler cet ennemi, plus on a de chances de 
l’aneantir. Dans cette perspective, aucun d’entre nous ne pourrait 
imaginer, ne serait-ce que quelques secondes, que Napoleon l er 
aurait pu vaincre tant d’ennemis sur tant de champs de bataille en 
s’appuyant seulement sur son intuition. Pour resoudre un probleme, 
il faut en connaitre la cause et pour trouver celle-ci, il faut user de 
strategic dans un raisonnement structure, rigoureux, mais aussi dans 
une logique d’enquete et d’exploration precise ou rien ne doit etre 
laisse au hasard. 

Les quelques principes suivants approfondissent le schema precedent. 
Etape 1. La definition d’un probleme repose sur les reponses que Ton 
glane a force de se poser la question « pourquoi », et ce jusqu’a ce 
qu’il n’y ait plus d’explication a donner. Bien definir un probleme est 
essentiel pour pouvoir le resoudre. 

Etape 2. Celui qui analyse un probleme dispose d’un resultat type qu’il 
compare avec la situation actuelle. Ce qui caracterise un probleme est 
la divergence par rapport au resultat attendu (le « devrait etre »). 

Etape 3- L’identification des causes possibles de divergence entre le 
« devrait etre » et les effets du probleme analyse passe par la localisa- 
tion des modifications qui se sont produites. Il est a noter que la 
cause possible ou probable est toujours correlee a une modification a 
un instant donne et qui peut avoir provoque un ou plusieurs des 
effets du probleme analyse. 

Etape 4. Il existe toujours une particularite qui doit differencier ce qui 
a ete touche par la cause du probleme de ce qui ne l’a pas ete. 

Etape 5. La cause la plus probable du probleme est celle qui verifie „ 
tous les effets repertories par la description globale du probleme. 1 
Le mode operatoire de la methode Kepner et Tregoe comprend done | 
les phases decrites ci-apres. | 



Gestion reactive des problemes 103 


Definir le probleme 

Toute analyse de probleme commence par ce point de passage 
oblige qui consiste a definir le probleme. Cette etape critique ne doit 
pas etre baclee. Beaucoup de problemes immatures dans leurs defi- 
nitions finiront par faire perdre un temps precieux a l’organisation, 
parce qu’au lieu d’avoir a mettre en place l’exploration des 2 ou 
3 pistes ciblees, la definition trouble et/ou trop large du probleme 
obligera a en explorer 3 fois plus ! 

Soit un probleme defini sous la forme suivante : « Le serveur a crashe 
chaque mardi depuis 3 semaines. Ceci ayant eu a chaque fois pour 
impact de rendre indisponible la messagerie pendant 2 heures. » 

Une meilleure definition du probleme devrait inclure plus d’informa- 
tions et pourrait etre : « Le serveur hebergeant la messagerie a crashe 
les mardis 2, 9 et 16 octobre 2007 a 1 h du matin. Chaque interruption 
de service a dure 2 heures. Ces crashs semblent lies a une operation de 
maintenance effectuee par les ingenieurs systeme a ces memes dates 
pour la mise en production de patch pour upgrader le serveur. » 

Pour developper la definition d’un probleme, une pratique usuelle- 
ment mise en oeuvre par nos chers enfants consiste a adresser syste- 
matiquement la question du pourquoi a l’explication qui vient d’etre 
donnee sur la definition du probleme. Cette methode appelee les 
« 5 pourquoi » (ou « 5 whys ») permettra d’optimiser la definition du 
probleme jusqu’a son maximum. 

Decrire le probleme 

Avec une definition claire du probleme, cette etape va consister a 
detailler le plus possible le probleme tel qu’il a ete defini. Le tableau 
ci-apres permet de cadrer l’exercice a mener pour cette etape, qui 
vous l’aurez compris, est un travail d’equipe. Utilisez un paper-board 
pour consigner toutes les informations du groupe de travail durant la 
seance de description du probleme. 

Dans ce tableau, nous avons 4 aspects : 

• Le « quoi » au sens « qu’est-ce que c’est ? ». 

• Le « ou » au sens « ou est-ce apparu ? ». 

g, • Le « quand » au sens « quand cela est-il apparu ? ». 

| • Le « se propage a » au sens « quels sont les impacts collateraux ? ». 
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Est 

Devrait etre mais 
n’est pas 

Differences 

Changements 

Quoi 

Detail sur le 
probleme 

Description du 
fonctionnement d’un 
systeme similaire ou du 
fonctionnement normal 
du systeme sur lequel 
est constate le 
probleme. 

? 

? 

Ou 

Description de la 
localisation du 
probleme 

Description des autres 
localisations non 
touchees par le 
probleme. 

? 

? 

Quand 

Description du 
chrono 
d’apparition 
(debut a fin) du 
probleme. 

Description d’autres 
periodes ou le 
probleme n’est pas 
apparu. 

? 

? 

Se 

propage a 

Description 
d’autres systemes 
touches par le 
probleme 
constate. 

Description d’autres 
systemes similaires ou 
assimiles, sur lesquels 
le probleme n’a pas ete 
constate. 

? 

? 


La colonne « Est » permet de decrire tout element d’information speci- 
fique au probleme donne. II s’agit de ce qui caracterise le probleme. 
La colonne « Devrait etre mais n’est pas » permet de decrire tout 
element d’information non specifique au probleme donne. 

Ces deux colonnes vont permettre d’eliminer les pistes d’analyses 
intuitives mais erronees, que Ton serait tente de prendre sans avoir 
fait cet exercice de comparaison. Celui-ci est formalise dans la 
colonne « Differences » ou Ton note le resultat comparatif entre les 
elements contenus dans les colonnes « Est » et « Devrait etre mais 
n’est pas ». Ces differences constituent la base du probleme. 


Etablir les causes possibles 

Etablir la cause possible, c’est done rechercher ce qui a pu changer 
dans le systeme pour provoquer la defaillance et done l’impact occa- 
sionne. La derniere colonne du tableau appelee « Changements » est 
alors utilisee pour lister l’ensemble des changements, des modifica- 
tions possibles du systeme pouvant expliquer les differences de fonc- 
tionnement formalisees dans la colonne precedente. 

Tout gestionnaire de problemes qui a passe du temps a comprendre J 
la cause d’un probleme a deja pu s’apercevoir que cette cause n’est J- 
parfois pas du tout celle a laquelle nous nous attendons le plus. II y a | 
tellement de changements qui peuvent influer sur le fonctionnement ° 
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du systeme et done du service que cette recherche revele bien 
souvent des surprises. 

Reprenons l’exemple de probleme de messagerie : «■ Le serveur heber- 
geant la messagerie a crashe les mardis 2, 9 et 16 octobre 2007 alb 
du matin. Chaque interruption de service a dure 2 heures. Ces crashs 
semblent lies a une operation de maintenance effectuee par les inge- 
nieurs systeme a ces memes dates pour la mise en production de patch 
pour upgrader le serveur. » 

En completant le tableau, les causes possibles sont mises en evidence 
et permettent d’elargir le champ de vision sur les solutions possibles 
pour resoudre le probleme. 



Est 

Devrait etre mais 
n’est pas 

Differences 

Changements 

Quoi 

Le serveur 
Exchange a 
crashe suite a 
I'application du 
patch pour 
upgrader des 
serveurs. 

Sur d’autres serveurs 
Exchange sur lesquels 
a ete applique le patch 
pour upgrader des 
serveurs. 

Differentes 
equipes 
(3 roulements 
differents) 
mettent en 
oeuvre ce meme 
type d'operation. 

Nouveau patch 
en provenance 
du constructeur. 

Ou 

En salle 
blanche n' 2 et 
sans presence 
du technicien 
support. 

Dans les salles 
blanches restantes 
(1,3, 4et5)avec 
presence du technicien 
support. 

L’operation est 
normalement 
effectuee avec 
la presence d’un 
technicien 
support. 

Nouvelle 
procedure mise 
en oeuvre. 

Quand 

Mardis 2, 9 et 
16 octobre 
2007, a 1 h du 
matin. 

N’importe quelle autre 
periode. 

Intervention de 
I’equipe n' 2 sur 
tous les 
creneaux du 2, 

9 et 16. 

C’est la 
premiere fois 
quel’equipen' 2 
effectue ce type 
d’operation. 

Se 

propage a 

Tous les 
serveurs 
Exchange de la 
salle blanche 
n’ 2. 

Tous les autres 
serveurs Exchange des 
autres salles blanches 
(1, 3, 4 et 5). 

Sans objet. 

Sans objet. 


Tester les causes les plus probables 

Les elements d’informations issus de la colonne « changements » 
listent les causes possibles. L’etape suivante consiste done a identifier 
| la liste reduite (short list) des causes les plus probables et pour ce 
I faire, a se poser la question suivante : 
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« Si tel element est la cause du probleme (au sens root cause - cause 
racine), cela explique-t-il ce que le probleme est et ce que le 
probleme devraitetre mais n ’est pas ? » 

L’exercice peut etre formalise par le tableau suivant. 


Cause possible Vrai si 

Nouveau patch en provenance du 
constructeur. 

D’autres serveurs ont le meme 
probleme. 

* 

Nouvelle procedure mise en oeuvre. 

La meme procedure crashe d’autres 
serveurs. 

** 

C’est la premiere fois que I’equipe 
n"2 effectue ce type d’operation. 

Le probleme n’est pas reapparu depuis 
les roulements de I’equipe n' 3 et n' 1 . 

*** 


Verifier les causes les plus probables 

Cette derniere etape va permettre de controler la liste reduite des 
causes sous-jacentes probables en partant a la recherche de tout 
indice permettant d’apporter la preuve que tel ou tel element est bien 
la cause qui explique l’ensemble des donnees collectees et consti- 
tuant la description du probleme. 

Cette etape franchie et les preuves a l’appui, la modification pour 
annuler les effets negatifs consecutifs au probleme peut etre decidee 
et mise en oeuvre. En tout etat de cause, quelle que soit la methode 
employee, l’investigation et le diagnostic d’un probleme peuvent 
s’averer d’autant plus longs que le probleme analyse est complexe. 

Strategic de correction des causes par la loi de Pareto 

La loi de Pareto part du principe que pour tout probleme, il y a toujours : 

• Un nombre restreint de causes qui, a elles seules, sont responsa- 
bles de la majeure partie de l’effet negatif. 

• Un nombre important de causes qui, dans leur totalite, sont respon- 
sables d’un pourcentage minime de cet effet negatif occasionne. 

Afin de mettre en oeuvre la meilleure solution pour diminuer les 
impacts negatifs du probleme sur Pactivite, il va done s’agir, lors des 
investigations et du diagnostic du probleme, d’identifier les causes les 
plus probables et de maitriser en priorite la conection de ces causes 
afin de reduire de fagon majeure l’effet negatif du probleme. » 

Cette methode permet de maitriser la conection du probleme de fagon J> 
pragmatique et d’etre maitre de l’effort a investir pour le resoudre en | 
fonction du potentiel d’impacts negatifs sur la qualite de service. ® 
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Prenons un exemple : sur un service ayant donne lieu a l’ouverture 
d’un probleme, nous avons ci-dessous liste les incidents numerates 
del a 15, enregistres entre janvier et mai avec : 

• la date d’enregistrement des incidents ; 

• les incidents associes au probleme ; 

• la priorite des incidents ; 

• la grille des causes probables de chaque incident. 

Sur ce dernier point, l’agregation des informations issues de la base 
Incident a permis d’identifier 9 causes probables, respectivement 
notees dans le tableau de A a I, meme si certains incidents ont 
plusieurs causes probables. 



Figure 4-8 : Modele d’une repartition d’incidents 
«, par type de causes probables 

| Cette liste montre que la definition du probleme a permis de rassem- 
I bier un nombre important d’informations. 11 faut se rendre a 
| l’evidence que plus les informations sont riches, plus les indices sont 
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importants et done Tissue au probleme pose plus proche. Cependant, 
attention a ne pas se perdre dans ce grand nombre d’informations. 

A partir de ces donnees, le diagramme de Pareto va permettre de deter- 
miner la priorite des actions a mener dans le cadre du plan de resolu- 
tion du probleme ainsi que les actions pertinentes a engager. La finalite 
est de quadriller la resolution du probleme en construisant le plan de 
correction qui va permettre d’agir en priorite sur les incidents qui affec- 
tent le plus fortement le service lorsqu’ils surviennent. On tient compte 
des informations suivantes issues du diagramme de Pareto : 

• la repartition du nombre de causes probables selon les causes de 
A a I ; 

• le tri du nombre de causes de A a I par ordre decroissant ; 

• le pourcentage cumule des causes apparues selon leur frequence 
par rapport au total. 


§ 

s 

s 



Figure 4-9 : Exemple de diagramme de Pareto 

Comme represente dans le graphique, les causes probables C, E, A et 
D sont responsables a hauteur de 78 % de Teffet negatif engendre 
par le probleme que nous cherchons a resoudre. Cette formalisation 
permet de mettre en evidence les elements du tableau ci-dessous : 



Causes majeures 
de I’effet negatif du 
probleme 

Cause probable 

Nombre 

d’occurrences de la 
cause probable 

Pourcentage sur le 
volume global 

Cause probable n - 1 

C 

10 

30% 

Cause probable n'2 

E 

7 

21 % 

Cause probable n - 3 

A 

5 

15% 

Cause probable n°4 

D 

4 

12% 
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Notre objectif etant toujours de diminuer l’impact negatif, nous allons 
orienter notre recherche de solution sur la cause probable qui nuit le 
plus au service selon la priorite des incidents qui lui sont associes. 
Dans ce principe, nous devrons d’abord traiter la cause n" 4. Celle-ci 
est en bas de liste dans le tableau precedent, mais c’est la cause qui 
occasionne les degats les plus nuisibles pour le service avec l’enregis- 
trement de 5 incidents de priorite 1 sur le service. 



Figure 4-10 : Croisement des incidents et des causes en priorite 1 

Le traitement de cette cause apportera le gain le plus important sur la 
qualite de service. Cette mise en evidence est structurante et Ton se 
rend bien compte que prendre une autre direction ne favorisera pas 
l’atteinte de l’objectif d’amelioration de la qualite de service. L’investi- 
gation est une etape cle dont le resultat est determinant pour la mise 
en oeuvre de la strategic de resolution du probleme. 

Une fois la cause n° 4 traitee, nous devrons ensuite traiter la cause 
n° 1. Bien que celle-ci soit en haut de la liste dans le tableau prece- 
dent, c’est la seconde cible a viser avec l’enregistrement de 
s 3 incidents de priorite 2 sur le service. 



ill 


Figure 4-11 : Croisement des incidents et des causes en priorite 2 


Enfin, une fois la cause n° 1 traitee, nous devrons nous focaliser sur 
les causes n° 2 et n° 3. II s’agit de la derniere cible a viser. Ces causes 
sont associees a 7 incidents de priorite 3 sur le service. 



/ 


Figure 4-12 : Croisement des incidents et des causes en priorite 3 

Quelles que soient les methodes utilisees pour enqueter sur un 
probleme, une certaine rigueur analytique est necessaire. 
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Ce qu’il faut eviter de faire 

• Parvenir a des conclusions avant d’avoir completement defini et 
compris le probleme. 

• Entamer la planification de la resolution a l’aide de solutions 
privilegiees intuitivement durant l’analyse. 

• Confondre la discussion autour d’un probleme et son analyse. 

• Se focaliser sur le contenu des arguments plutot que sur le 
processus d’analyse qui doit structurer la demarche d’analyse. 

Une bonne pratique a retenir 

Reformuler le probleme de fagon a le comprendre pleinement. Cette 
pratique habituellement mise en oeuvre dans le cadre de brainstor- 
ming doit permettre de faire tomber les prejuges et de liberer la 
reflexion, de faire tomber les schemas de pensees preetablis et 
d’ouvrir l’exploration d’autres voies d’analyse. Ce type de reformula- 
tion n’est pas evident pour tout le monde. Voici quelques 
suggestions : 

• Retournez le probleme. Si le probleme est : « comment encoura- 
ger plus de gens a travailler ? », posez-vous la question inverse : 
« qu’est-ce qui decourage les gens de travailler ? ». Cette approche 
ouvre de nouvelles possibilites de reflexion et bouscule les preju- 
ges. 

• Prenez du recul/Formulez le probleme de fagon plus generale. 
Plutot que de vous demander : « Est-ce qu’il faut changer de fagon 
de travailler ? » (Oui ? Non ? Peut-etre ?), demandez-vous : « De 
quelle fagon pouvons-nous encore ameliorer notre professionna- 
lisme ? ». Le probleme est ainsi formule de fagon plus claire, ce 
qui ouvre d’autres options de reflexion. 

• Identifiez la cause. Posez la question du pourquoi. Plutot que de 
vous demander : « Est-ce qu’il faut changer de fagon de travailler ? », 
demandez-vous : « Pourquoi avons-nous besoin de changer notre 
fagon de travailler ? » Pourquoi ? Etc. 

s • Changez de perspective. Identifiez le coeur de la question mais 
J. placez-vous sous un angle different. Ainsi, « Dois- je changer de 
| fagon de travailler? », peut devenir : « Comment pourrais-je 
| evoluer / faire evoluer, mon travail, mon poste, mon activite ? » 
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La resolution et la cloture des problemes 


Quelques types d'exemples : 

1. Modification du SI (qui fait I'objet 
d'une demande de changement). 

2. Production d'un document 
d'exploitation (fiches de taches, 
mode operatoire, arbre de 
decisions). 

3. Formations. 

4. Etc. 


Figure 4-13 : Fiche memo de la resolution et de la cloture des problemes 

La resolution et la cloture d’un probleme sont conditionnees par la 
mise en oeuvre d’une solution provisoire dans le SI : 

1. Modification du SI (qui fait I’objet d’une demande de changement). 

2. Production d’un document d’exploitation (fiches de taches, modes 
operatoires, arbre de decisions). 

Pour le cas n°l : la mise en place de solutions provisoires necessitant la 
mise en oeuvre d’une modification dans le systeme d’information doit 
faire I’objet d’une demande de changement. Toute demande de change- 
ment urgente doit obligatoirement suivre les regies en vigueur prevues a 
cet effet, dans le cadre du processus gestion des changements. 

De fagon generate, en cas de litige concemant remission d’une 
demande de changement, il est recommande de se referer au gestion- 
naire du processus pour arbitrage. 

Pour le cas n°2 : toutes les solutions provisoires doivent faire I’objet 
destructions formalisees dans un mode operatoire a l’usage des 
acteurs du processus de la gestion des incidents. Celui qui a identifie la 
solution provisoire est responsable de la validation de ce document, 
avant sa mise en application par les acteurs de la gestion des incidents. 
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Passage d’un probleme en erreur connue 

Une erreur connue est une situation identifiee avec succes par le 
diagnostic des causes premieres d’un probleme (a ne pas confondre 
avec la notion de cause initiale sur la gestion des incidents) et par la 
mise en place consecutive de la solution provisoire (palliative ou de 
contournement). 

La cause identifiee d’un probleme est une defaillance d’un element 
de configuration (materiel, logiciel, documentation, procedure). Si 
aucun element de configuration n’est en cause, il faut creer un 
element de configuration factice pour fermer le probleme. 

Exemple : pour un probleme lie a un manque general et connu de 
formation des utilisateurs, il faut creer un element « Probleme de 
formation » et passer le probleme en erreur connue sur cet element. 
Pour rappel, la methode ITIL preconise que toutes les documentations 
sur l’infrastructure doivent etre disponibles autant pour les applica- 
tions, le systeme d’exploitation et le socle logiciel que pour le reseau. 


L’identification et l’enregistrement des erreurs 
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Une erreur est identifiee lorsque l’element de configuration (Cl) en 
faute est detecte. Cet element est celui qui cause ou peut causer des 
incidents. Pour rappel, le statut d’erreur connue est assigne lorsqu’a ce 
stade, la cause premiere du probleme est cemee ET qu’une solution 
provisoire (ou de contournement) a ete trouvee et mise en place. 
Deux sources d’erreurs connues sont a distinguer : celles en prove- 
nance de l’environnement de production et de l’environnement de 
developpement (livraison d’application avec erreurs connues). 
L’enregistrement des erreurs passe par le referencement d’un docu- 
ment d’exploitation en version applicable dans une base referentielle 
appelee la base des Erreurs Connues (c’est une base de connaissan- 
ces). Les informations qui vont constituer la base des Erreurs 
Connues devront systematiquement etre reutilisees par la gestion des 
incidents en cas de reproduction d’incident(s) de meme type. 

L’ evaluation des erreurs 



Evaluer les erreurs, c'est etudier la mise en 
oeuvre d'une solution definitive : 

Scenario 1, 

Scenario 2, 

Etc. 

Et de choisir la meilleure (efficacite, ROI, 
business case) 



Figure 4-15 : Fiche memo de revaluation des erreurs | 

Evaluer les erreurs, c’est etudier la mise en oeuvre d’une solution | 
definitive. II s’agit done d’etudier, de planifier et de mettre en oeuvre ® 
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une solution fiable et perenne qui va permettre de clore definitive- 
ment le probleme et son erreur connue. Cette solution doit egale- 
ment etre celle du meilleur cout de revient : c’est la solution perenne 
a un cout maitrise (et done incluant le retour sur investissement le 
plus pertinent). 

II faut savoir et accepter que toutes les erreurs connues ne fassent 
pas l’objet d’une telle solution pour des raisons de rentabilite. II s’agit 
done d’une decision qui merite reflexion : une bonne pratique 
consiste a confronter plusieurs scenarii differents dans leur perti- 
nence a repondre a l’objectif de traitement definitif de la cause, tout 
en jaugeant pour chacun le cout d’implementation, les risques et les 
gains. 

II faut tenir a une resolution parce qu’elle est bonne, et non parce 
qu’on l’a prise [La Rochefoucauld], 

Pour s’assurer de prendre la bonne decision, il est necessaire 
d’evaluer les risques de fagon pertinente. Il est recommande d’avoir 
mis a l’epreuve les scenarii de solutions en liste reduite » en effec- 
tuant tout controle et verification possible sur les environnements de 
test avant mise en production. Le groupe d’intervention d’experts a 
done la responsabilite d’evaluer toute solution finale devant etre 
implementee en production sur des criteres de faisabilite technique, 
de cout, de gains et de risques. 


Pendant la recherche de la solution definitive, il peut etre necessaire de mettre 
le systeme sur un niveau de trace superieur au fonctionnement habituel. N'en 
doutez pas, il s’agit d’un changement qui doit imperativement faire I’objet d’un 
controle par le processus de gestion des changements. 


Retenez les points pratiques suivants, concernant l’interaction avec le 
processus de gestion des changements : 

Les preconisations visant a implementer un niveau de traces non 
usuel dans le cadre de l’exploitation recurrente devront toutes faire 
| l’objet d’une demande de changement. Lors de son investigation, 
I l’expert pourra proposer ce type de preconisation. Cette demande de 
| changement devra imperativement avoir ete validee par ses soins 
| avant emission vers les poles de gestion des changements. 
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Les tests de solutions sur les environnements de production sont a 
proscrire par defaut. Pour les cas aux limites de cette regie, une dero- 
gation ecrite du management est preconisee. Cette derogation ne doit 
bien evidemment pas exclure l’obligation de formaliser et d’emettre 
une demande de changement pour prise en compte de la (ou des) 
modification(s). 

Toutes les etapes d’analyse d’impact, de test de validation, de modifi- 
cation de l’element de configuration doivent etre sous le controle de 
la gestion des changements. 


La consultation de fichiers log ne fait pas I’objet d’une demande de 
changement. En effet, il ne s’agit ni d’une modification, ni d’une suppression, 
ni d’un ajout d’un element de configuration. 


Devaluation selon la methode de Kepner & Tregoe 

La methode d’Analyse et Decision (AD) de Kepner & Tregoe, permet 
de faire le choix pertinent entre plusieurs solutions. Cette methode a 
pour objectif de faire le tri entre plusieurs solutions, de clarifier 
l’objectif vise, d’evaluer les risques et les gains pour faire le choix le 
plus pertinent et prendre la decision la plus solide possible. 

Cette methode se base sur 5 etapes representees par le schema ci-dessous. 


4 



1 


Figure 4-16 : L’ evaluation des erreurs de Kepner & Tregoe 

3 

Les quelques principes pour commenter ce schema : 1 

1. « Quel probleme nous attachons-nous a resoudre definitivement ? », | 

la definition d’une decision dependant de l’objectif vise. ® 
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2. Pour ne pas se tromper d’objectif, l’ordre d’importance caracterise par 
la priorite attribute aux problemes est (et doit rester) le fil conducteur. 

3. Une fois les objectifs etablis, toutes les options visant a repondre 
aux objectifs doivent etre recensees. Les options ayant les meilleures 
chances d’atteindre l’objectif vont constituer la « decision provisoire ». 

4. L’examen de la (ou des) « decision(s) provisoire(s) » doit permettre 
de determiner toutes les consequences nuisibles eventuelles. 

5. Le choix de la decision finale est une decision de confiance. Mais 
la confiance n’exclut pas le controle. Le zero risque n’existe pas. La 
decision a besoin d’etre suivie et controlee dans son application afin 
de mener a bien la gestion du changement. 


L’enregistrement de la resolution de l’erreur 



Objectif de I'activite : 

proposer un changement pour implementation de la solution definitive 



L'enregistrement de la solution passe par la formalisation 
d'une demande de changement. 


Quelques exemples : 

Patch correctif de bug logiciel 

Projet de fiabilisation 

Mise a jour de manuel d'exploitation 

Mise a jour de specification de supervision 

Mise a jour de specification d'automatisation 

Mise a jour de configuration du systeme (parametrage, 

etc.) 

Etc. 



Figure 4-17 : Fiche memo de l’enregistrement de la resolution de I’erreur 

L’enregistrement detaille de la resolution est une etape essentielle qui 
| va profiter a l’organisation tout entiere et notamment au processus de 
| gestion des incidents. Cela permet aux acteurs du processus de reagir 
I de la fagon la plus efficace possible en cas d’apparition d’incidents 
| rattaches au probleme en cours de traitement. 
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L’enregistrement de la resolution d’une erreur consiste (comme pour 
certaines solutions provisoires) a l’enregistrement d’un changement. 

Cldture des erreurs et des problemes associes 

La cloture des problemes devrait etre exclusivement effectuee par les 
supports qui ont le moyen de s’assurer au quotidien de la non-repro- 
duction des incidents associes au probleme traite. 



Objectif de I'activite : clore definitivement les problemes et les erreurs connues 


La cloture de I'erreur et du probleme associe s'effectue apres une 
periode d'observation definie. 

Durant cette periode d'observation : 

- S'assurer de la non-reproduction des incidents relatifs au 
probleme traite. 

- Verification/reevaluation du nombre d'incidents eradiques. 

- Analyse pour evaluation du nombre de points de QoS gagnes 

Pour des besoins de reporting, un indicateur doit permettre de 
suivre les problemes sous observation (avant cloture). 



Figure 4-18 : Fiche memo de la cloture des erreurs 
et des problemes associes 

La periode d’observation permet d’eviter la reouverture de problemes 
que Ton pensait deja traites. 

Toutes les periodes d’observation avant cloture d’un probleme 
devraient etre validees en comite de suivi des problemes. Ce dernier 
peut egalement definir des criteres specifiques de sortie de gestion 
du probleme qui devront alors faire l’objet de verification. A Tissue 
de la periode d’observation, deux cas de figure sont possibles : 

• Dans le cas ou la periode d’observation permet de verifier la non- £ 
reproductibilite des incidents associes au probleme traite, la | 
cloture definitive du probleme peut done etre effective. ® 


Iln|i ill! 
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• Dans le cas ou la periode d’observation ne permet pas de verifier 
la non-reproductibilite des incidents associes au probleme traite, 
celui est reaffecte au dernier support en charge pour reevaluation 
de l’erreur. 

II faut neanmoins observer que tous les problemes n’arriveront pas 
jusque-la. Pas de complexe, c’est normal. Les problemes qui font 
l’objet de la mise en place d’une solution definitive doivent etre ceux 
pour lesquels cette solution est techniquement possible et represente 
un retour sur investissement interessant. 

II est done possible que certains problemes ne fassent pas ou ne 
puissent pas faire l’objet de la mise en place de solution definitive. 
Dans ce cas, les erreurs connues associees a ces problemes resteront 
ouvertes (et cela ne doit stresser personne). 

La gestion reactive des problemes avec Sex Sigma 

Cette partie a pour objectif de presenter les bases de la 
methode de resolution des problemes de Six Sigma appelee 
DMAIC. 

Sont inclus dans ce chapitre les fondamentaux a integrer en 
matiere de mise en oeuvre de la methodologie pour la resolu- 
tion des problemes. 

Nous apporterons des reponses aux questions suivantes : 
Qu’est-ce que Six Sigma ? 

Quels sont les principes de la methode DMAIC ? 

Comment s’en servir ? 

Pour completer ce dont nous avons besoin d’apprendre en matiere de 
gestion reactive des problemes, nous ne pouvions pas manquer de 
vous parler du processus de resolution des problemes de Six Sigma. 
Dans sa forme initiale la plus simpliste, la methode de resolution des 
problemes de Six Sigma appelee le « DMAIC » se compose a l’origine 
„ de 5 etapes decrites dans le schema suivant. 

| En soit, cette methode de resolution des problemes reste dans la 
I lignee des precedentes, et fait penser a la methode 8D dans son arti- 
| culation. Son principe de base est au demeurant particulierement 
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Figure 4-19 : Le DMAIC de Six Sigma 


complementaire et structurant puisque centre sur la mesure. C’est la 
philosophic du « je mesure, done j’ameliore » ! 

II s’agit d’une methode de resolution des problemes de qualite 
couramment utilisee dans le monde industriel et developpee initiale- 
ment par Motorola. Cette methode vise a eliminer les defauts 
pouvant survenir lors de la prestation de services, mais s’applique 
egalement dans le cadre du management de l’organisation d’une 
entreprise. L’utilisation du procede necessite une formation de 
l’ensemble du personnel implique dans son application. Comme 
toujours, la reussite de toute demarche methodologique de resolu- 
tion de problemes tient dans l’effort de conduite du changement 
(nous ne le rappellerons jamais assez). 

Cette methode de resolution des problemes est peu promue dans le 
milieu informatique, et pourtant tres populaire en tant que bonnes 
pratiques grace aux success stones de grandes entreprises comme 
General Electric dont le PDG Jack Welch avait declare « Six Sigma est 
la plus importante initiative que General Electric ait jamais prise - 
c’est une partie du code genetique de notre futur leadership. » Pour la 
petite histoire, J. Welch attribue a la mise en place de la methode de j 
resolution des problemes de Six Sigma, l’economie de plusieurs J. 
milliards de dollars. Motorola, qui est a l’origine de l’invention et du | 
developpement de cette approche methodologique, a rapporte une ° 
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economic de 11 milliards de dollars depuis que Six Sigma a ete 
implementee dans ses usines il y a une dizaine d’annees. 


Le concept Six Sigma 

Le terme Six Sigma est la denomination de l’objectif vise. Il s’agit d’une 
approche statistique dont l’enjeu est de reussir a converger vers le 
nombre de defauts le plus infime possible. Ce nombre infime corres- 
pond alors a la probability la plus mince de non-qualite pouvant surve- 
nir, et est associe a une valeur de tolerance egale a trois ecarts types de 
chaque cote de la moyenne statistique, soit Six Sigma. 


Limites inferieures 


Limites superieures 


t Objectif 6 a = 
'A specifications 


-60 -30 - 1 o 


Non-qualite possible 


+30 +60 


Figure 4-20 : Le concept Six Sigma 


La methodologie de resolution des problemes de Six Sigma 

La methode Six Sigma est une bonne pratique reconnue mondiale- 
ment, qu’il nous semble opportun de rallier aux bonnes pratiques de 
gestion reactive des problemes. Il est dommage qu’ITIL n’en fasse 
pas singulierement etat. 

Les 5 principes mis en oeuvre par cette methode sont les suivants. 

Definir 

Ce point de demarrage est incontournable dans la philosophic de 
resolution des problemes. L’etape de definition permet de cadrer le 
contexte du probleme, les objectifs que Ton se fixe pour atteindre le 
| niveau de reduction de la non-qualite le plus fort possible (le nombre 
J. de sigmas ou d’ecarts types le plus eleve). Pour ce faire, il va s’agir 
| d’identifier ce que l’on appelle le Critical To Quality (CTQ), c’est-a- 
| dire les points critiques pour la qualite. 
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• Les bonnes questions a se poser sont : quel est le probleme ? Qui 
sont les clients ? Quel est le niveau de service vise et quels sont 
les niveaux d’exigences demandes par les clients ? 

Mesurer 

II s’agit de la collecte des donnees pertinentes en lien avec le probleme 
defini. Cela passe par le rassemblement des faits, et de tout element 
permettant d’avoir une vision objective du probleme a traiter. 

Les bonnes questions a se poser sont : quels sont les faits ? Quel est 
l’etat de la performance actuelle (ou de la non-performance) ? Quel- 
les sont les variations de performance ? Ou sont les zones de 
progres ? Quelles sont les metriques permettant de constater les 
consequences du probleme sur la qualite ? 

Analyser 

L’analyse est l’enquete qui va permettre de mettre en evidence les 
causes sous-jacentes les plus probables afin de focaliser l’etude sur 
un plan d’action permettant d’eradiquer ces causes. Cette analyse se 
concentre sur la reduction de l’ecart entre l’objectif vise (etabli dans 
l’etape de la definition du probleme) et les elements de mesure 
constates (choisis a l’etape de la mesure). 

Les bonnes questions a se poser sont : quand la non-qualite se 
produit-elle ? Ou ? Comment ? Pourquoi ? 

Quelles sont les sources qui influent negativement sur la variation de 
la qualite de service ? Comment hierarchiser les opportunites 
d’ameliorations mises en evidence ? 

Innover 

On entend par innovation, la demarche de developpement et de 
mise en place du plan d’action qui va permettre de faire evoluer l’etat 
problematique en un etat de qualite, et ce par la reduction ou l’annu- 
lation des consequences nuisibles de la non-qualite. 

Les bonnes questions a se poser sont : quelles solutions mettre en 
place pour realiser la performance ou atteindre la qualite souhaitee 
telle que formalisee dans l’etape de la definition du probleme ? 
Comment les mettre en place ? 

Controler 

Cette etape de surveillance est necessaire a l’observation des solu- 
tions mises en place. L’objectif est de suivre les resultats des actions 
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effectuees, de piloter l’amelioration de la qualite en controlant les 
variations, et de prevoir tout retour en arriere ou regression poten- 
tielle de l’amelioration et done de la qualite. 

Les bonnes questions a se poser sont : comment surveiller la perfor- 
mance pour atteindre le niveau de qualite vise ? Comment piloter les 
variations possibles risquant de compromettre la qualite visee ? 


Tableau 4-1 : Ce qu’il faut retenir, dans une traduction mathematique 
du questionnement de la demarche 


Etapes 

Phase 

du Questions 

DMAIC 

1 . Comprendre quels sont le 
probleme et I’amelioration a 
engager, et definir les buts a 
atteindre. 

Definir 

Quelle est la valeurY de la qualite a 
obtenir ? 

2. Mesurer I’etat courant. 

Mesurer 

Quelle est la valeurY actuelle ? 

3. Dans une reflexion de cause a 
effet, etablir ce qui peut causer le 
probleme defini. 

Analyser 

Quelles sont les valeurs X des causes 
probables ? 

4. Rechercher les vraies causes 
de la survenance du probleme, 
e’est-a-dire celles qui de fagon 
prouvee corroborent la relation 
de cause a effet. 

Quelles sont les valeurs X causant de fagon 
averee le probleme ? 

5. Mener les actions necessaires 
pour mettre en oeuvre la solution. 

Innover/ 

Ameliorer 

Comment la formule Y = f(X) peut-elle etre 
exploitee ? 

Comment la comprehension et la 
connaissance des causes X du probleme 
peuvent-elles etre exploitees pour eliminer 
ou reduire au maximum la taille des impacts 
lies au probleme. 

6. Mesurer pour verifier 
I'amelioration. 

Controler 

Est-ce qu’Y s'est reellement ameliore ? 

7. Prendre les actions 
necessaires pour preserver les 
gains obtenus, suite aux 
ameliorations engagees. 

Comment les X peuvent-ils etre controles 
pour preserver et ameliorer en continu Y ? 


1 24 Ameliorer la qualite des services 


Pourquoi penser que le DMAIC est une bonne pratique 
de gestion des problemes ? 

Outre la pertinence des cinq phases du processus presente prece- 
demment, un enseignement applicable a tout probleme se degage de 
cette methode. 

Dans une demarche de gestion de problemes, et ce quels que soient 
Poutil, la methode, le mode operatoire que Ton souhaite utiliser, nous 
pouvons retenir les citations suivantes : 

• « II n’y a pas de probleme sans une definition claire de son effet 
par rapport a un etat defini comme le fonctionnement normal. » 

• « II n’y a pas de probleme defini sans une mesure objective de ses 
effets. » 

• « II n’y a pas de mesure objective des effets d’un probleme sans 
une analyse de cette mesure. » 

• « II n’y a pas d’analyse des effets d’un probleme sans une issue 
favorable a l’amelioration ou a l’innovation permettant de faire 
evoluer l’etat problematique vers l’etat de fonctionnement normal 
escompte. » 

• « II n’y a pas d’amelioration ou d’innovation mise en oeuvre sans 
controle de leur effet sur l’etat a modifier. » 

Synthese de la Gestion reactive des prob lem es 

Cette partie a pour objectif de faire un recapitulatif sur la 
gestion reactive des problemes. 

Nous etablirons une synthese du fonctionnement du proces- 
sus reactif de la gestion des problemes ainsi que la fiche des- 
criptive de chaque activite de ce processus. 

Nous apporterons des reponses aux questions suivantes : 

Quels objectifs ? Quels livrables ? Quels outils ? 

Quels moyens de mise en oeuvre ? 

Quel mode de suivi ? 
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Figure 4-21 : BoTte grise de la gestion reactive des problemes 
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Identification et enregistrement des problemes 


Objectif de I’activite : Detecter et saisir tous les problemes dans une base unique 

Quels outil / moyen : 

Detection des incidents eligibles a la gestion des problemes. 

Quel livrable : 

Probleme enregistre dans la base des Problemes avec un n‘ de 
reference unique. 

Mode de suivi : 

Comite de suivi des problemes (surveillance et controle des 
problemes et des erreurs) et workflow (suivi au quotidien). 


Classement des problemes 


Objectif de I’activite : Determiner la priorite de traitement et le groupe de support 

Quels outil / moyen : 

Matrice devaluation des impacts de services et des niveaux 
d’impact sur la qualite de service. 

Quel livrable : 

Probleme priorise. 

Mode de suivi : 

Comite de suivi des problemes (surveillance et controle des 
problemes et des erreurs) et workflow (suivi au quotidien). 


Investigation et diagnostic des problemes 


Objectif de I’activite : Trouver la cause et la solution provisoire associee 

Quels outil / moyen : 

Acces aux environnements de production, Diagramme 
d’lshikawa, Methode 8D, PDSM de Kepner & Tregoe, 

« 5Whys ». 

Quel livrable : 

Detail de la cause et des solutions provisoires retenues. 

Mode de suivi : 

Comite de suivi des problemes (surveillance et controle des 
problemes et des erreurs) et workflow (suivi au quotidien). 


Resolution et cldture des problemes 


Objectif de I’activite : Implementer la solution provisoire 

Quels outil / moyen : 

Acces aux environnements de production et si necessaire au 
mode operatoire et aux pratiques en vigueur du processus de 
gestion des changements. 

Quel livrable : 

Solution implementee dans I’environnement de production (la 
solution peut etre une documentation). 

Mode de suivi : 

Comite de suivi des problemes (surveillance et controle des 
problemes et des erreurs) et workflow (suivi au quotidien). 
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Identification et enregistrement des erreurs 


Objectif de I’activite : Capitaliser sur les causes et les solutions provisoires trouvees 

Quels outil / moyen : 

Base des Erreurs connues. 

Quel livrable : 

Donnees associees aux erreurs, enregistrees dans la base. 

Mode de suivi : 

Comite de suivi des problemes (surveillance et controle des 
problemes et des erreurs) et workflow (suivi au quotidien). 


Evaluation des erreurs 


Objectif de I’activite : Proposer une solution definitive pour la non-reproductibilite 

Quels outil / moyen : 

Acces aux environnements de tests, PDSM de Kepner - 
Tregoe. 

Quel livrable : 

Recommandations a mettre en oeuvre pour resoudre 
definitivement le probleme. 

Mode de suivi : 

Comite de suivi des problemes (surveillance et controle des 
problemes et des erreurs) et workflow (suivi au quotidien). 


Enregistrement de la resolution des erreurs 


Objectif de I’activite : Implementer la solution definitive 

Quels outil / moyen : 

Mode operatoire et pratiques en vigueur du processus de 
gestion des changements. 

Quel livrable : 

Demande de changement emise vers la gestion des 
changements. 

Mode de suivi : 

Comite de suivi des problemes (surveillance et controle des 
problemes et des erreurs) et workflow (suivi au quotidien). 


Cldture des erreurs et des problemes associes 


Objectif de I’activite : Clore definitivement les problemes et les erreurs connues 

Quels outil / moyen : 

Acces aux environnements de production. 

Quel livrable : 

Rapport d’execution du changement implementee avec succes, 
periode d’observation de la non-reproduction validee et dossier 
Probleme + Erreur connue clotures dans le workflow. 

Mode de suivi : 

Comite de suivi des problemes (surveillance et controle des 
problemes et des erreurs) et workflow (suivi au quotidien). 
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Retenons que contrairement au processus de gestion des incidents 
qui recherche la cloture de tous les incidents, le processus de gestion 
reactive des problemes poursuit la cloture des problemes par l’imple- 
mentation d’une solution provisoire (si le probleme est important 
pour l’activite) et par l’implementation d’une solution definitive (si le 
jeu en vaut la chandelle), et ce dans l’esprit permanent d’une qualite 
de service perenne et au meilleur cout. 


© 



Chapitre 4 

Gestion proactive des problemes 


LeS DEUX ETAPES DU PROCESSUS PROACTIF 

Cette partie a pour objectif de detailler le fonctionnement du 
processus de gestion proactive des problemes. 

Nous aborderons, pour chacune des activites, les objectifs, 
les enjeux, les livrables associes et les bonnes pratiques a 
retenir. Nous tacherons egalement de presenter quelques 
outils/moyens pouvant etre mis en oeuvre pour la gestion et 
la resolution proactive des problemes. 

Nous apporterons des reponses aux questions suivantes : 
Comment detecter des problemes en mode proactif? 

Grace a quels moyens ? 

Comment traiter les problemes decouverts en mode proactif? 

La gestion proactive des problemes vise a se concentrer sur le traite- 
ment des problemes (identification et resolution) avant que les inci- 
dents ne surviennent. Cette partie du processus apporte la garantie 
d’un maintien de la qualite de service tout en gardant conscience des 
difficultes potentielles et par consequent en evitant les impacts sur 
l’activite de l’entreprise. 
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L’ analyse de tendance 


Analyse 

tendances 


Objectif de I'activite : identifier les problemes recurrents 


L'analyse des tendances, c'est etudier : 



- les revues emises par la gestion des incidents 

- les revues emises par la gestion reactive des problemes 

- les reclamations clients 

Dans le but de mettre en evidence : 

- les defauts insidieux provoquant la defaillance de sous-ensembles 
techniques ou de services (le probleme recurrent) 

- les besoins d'informations, formations, modes operatoires, etc. 


Figure 5-1 : Fiche memo de l’analyse de tendance 

L’analyse de tendance est un levier structurant pour regagner la 
confiance de vos clients. C’est par la que va passer l’elimination de 
tous les tracas que le service est susceptible d’endurer, mais qu’il ne 
subira finalement pas, car vous aurez prevu que tel ou tel dysfonc- 
tionnement pouvait arriver. 

Cette analyse repose notamment sur la pertinence des rapports 
produits par la gestion des incidents et la gestion des problemes 
concernant, par exemple, les causes les plus frequentes de pannes de 
tel ou tel systeme. C’est une veille active consistant a observer le 
systeme tel qu’il fonctionne au quotidien. Cette observation va 
permettre de deceler des elements d’informations qui, pour certains, 
pourront sembler anodin de prime abord, et finalement apres 
surveillance et comparaison par rapport a des periodes, pourront se 
reveler etre des signes annonciateurs de defaillances futures. g 

L’analyse de tendance peut egalement s’appuyer sur les informations J. 
disponibles par l’intermediaire de rapports generes par des logiciels, | 
des seminaires entre experts, ou encore des forums utilisateurs. La ® 
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encore, la loi de Pareto s’applique : 20 % des clients sont a l’origine 
de 80 % des reclamations. 

Vous l’aurez compris, cette activite est du ressort de ce que Ton pour- 
rait appeler usuellement la veille technologique. C’est Part de 
s’appuyer sur le passe pour prevoir l’avenir. Partager l’experience et 
la memoire est la cle du succes. 

Initialisation d’actions preventives 


des 

tendances 


Objectif de I'activite : 

identifier les actions recurrentes en anticipation de defaillances possibles 


II s'agit d'identifier les actions ciblees qui vont permettre 
de faire de la prevention recurrente : 



Exemple : 

- reboot de serveur tous les 6 mois 

- reorganisation de base de donnees tous les 3 mois 

- changement de carte memoire ou de CPU tous les ans 

L'identification de ce type d'action permet de faire 
suivre une demande de changement pour correction 
preventive. 


Cette maintenance anticipative des composants du SI 
permet d'eviter des incidents et des problemes. 



Figure 5-2 : Fiche memo de I’initialisation d’actions preventives 

La finalite de cette activite est de mettre en oeuvre : 

• Une analyse des problemes potentiels par rapport aux actions 
planifiees ou deja menees. 

• Une analyse des opportunities permettant de mettre en lumiere les 
„ gains possibles suite a la duplication d’une action preventive 
| appliquee a un systeme sur d’autres systemes similaires. 

I Les actions preventives que Ton met en oeuvre dans le systeme 
| d’information sont finalement la preuve d’une maitrise de la techno- 
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logie exploitee pour rendre le service. C’est un confort essentiel pour 
le client. 

Prenons l’exemple de notre voiture : nous savons qu’a une periode 
predefinie a l’avance, nous avons l’obligation de soumettre notre 
vehicule au controle technique. Pourquoi ? Parce qu’il est etabli, par 
l’analyse des tendances effectuees sur la fiabilite des voitures, qu’a 
partir d’un certain moment certaines pieces risquent de tomber en 
panne, ou tout du moins ont besoin d’une revision et d’une mainte- 
nance technique. Et c’est souvent le cas. . . 

Cette pratique offre l’avantage d’une meilleure longevite de la 
voiture, l’assurance pour le client d’en faire un usage en toute secu- 
rity et l’economie sur le cout de pannes plus serieuses, si elles 
n’avaient pas ete decelees en amont. 

C’est exactement la meme chose pour notre systeme d’information et 
done pour nos clients qui l’utilisent au quotidien. Evidemment, vos 
clients prefereront (et se sentiront plus en confiance) si vous leur 
annoncez a l’avance (voir dans le contrat de service) que des plages 
de maintenance sont necessaires pour rendre optimal l’usage de leur 
service, d’autant que vous les aurez prevenus a l’avance sur le temps 
d’indisponibilite necessaire pour organiser cette maintenance preven- 
tive, et que vous aurez decide avec leur accord du creneau d’inter- 
vention pour ces actions. 

Ce type de pratique, en plus de securiser le systeme d’information, 
renforce la confiance du client vis-a-vis de l’informatique. 

Tout client sera toujours plus apte a comprendre que l’informatique 
peut tomber en panne. Seulement il est plus aise de le comprendre 
lorsqu’il s’agit de determiner des plages d’intervention pour prendre 
les mesures preventives afin de garantir le bon fonctionnement du 
systeme, plutot que lorsqu’il s’agit de s’accommoder d’une panne 
survenue, comme c’est souvent le cas, au moment ou Ton a le plus 
besoin d’utiliser le service informatique. 

Apport d’information a l’organisation 

Cette activite enrichit perpetuellement l’organisation. Elle permet a 
une DSI d’etre a l’affut de ce qu’il faut prevoir pour un meilleur SI au J 
service de ses clients. Cela peut s’averer indispensable pour certains |> 
systemes dont nous savons que les plates-formes de tests ne sont pas | 
completement dans la logique ISO. | 
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C'est une pierre angulaire entre la 
production des services et le 
developpement des services. 

Cette activite vise a fournir a 
I'organisation les recommandations des 
experts pour ameliorer, faire evoluer le 
systeme d'information et sa capacite a 
maintenir la qualite de service rendue. 

Cette activite peut egalement donner 
issue a la redaction de documentations 
destinees aux utilisateurs pour un 
meilleur usage des services 
informatiques. 


Figure 5-3 : Fiche memo de I’apport d’information a I’organisation 


Dans ce cadre, les experts ont toute latitude pour emettre des 
besoins pour 1’evolution des automates de production, des processus 
fonctionnels, des infrastructures techniques, et tout autre composant 
du SI afin d’aligner la capacite de l’informatique de production des 
services avec les enjeux metiers. 

Ces apports d’informations issus de la gestion proactive des proble- 
mes prennent une dimension transversale car ils sont susceptibles 
de faire intervenir les competences de la direction de developpe- 
ment de services pour la remise en question de choix d’architec- 
ture, de conception de services, ou de developpement des produits 
exploites. 

C’est un plus pour la production informatique en lui permettant 
d’etre un acteur pertinent en amont des projets pour exiger (avec 
un dossier bien instruit) des solutions aux normes d’exploitabilite 
« coherentes avec les exigences presentes et futures des clients. 

J- Pour exemple : prenons le cas d’un fabricant de montres de luxe. 
I Observateur de sa clientele, il constate que ces montres sont, certes, 
| prisees par de nombreux clients, mais malheureusement ces derniers 
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ne les portent pas au quotidien, notamment pour aller au bureau. 
Force est de constater que les modeles produits sont tellement 
precieux qu’ils ne vehiculent pas une image de solidite. Cette obser- 
vation va permettre a l’organisation d’en tenir compte pour le 
prochain produit mis sur le marche : 

• l er choix possible : produire un modele qui va caracteriser la 
solidite a toute epreuve, permettant ainsi de renforcer la 
confiance de sa clientele actuelle, d’engranger des ventes aupres 
de ces memes clients, qui reconnaitront dans son nouveau 
modele la montre qu’il leur faut pour tous les jours, et surtout 
prendre des parts de marche en seduisant une toute nouvelle 
clientele plus sportive. 

• 2 e choix possible : produire une evolution du modele initialement 
propose, dans une declinaison plus sportive qui va ainsi caracteri- 
ser la solidite a toute epreuve, avec les memes benefices que 
precedemment. 

La gestion proactive des problemes est une gestion qui doit se 
concentrer sur l’essentiel : se focaliser sur 20 % des incidents et 
problemes susceptibles de se produire et pouvant affecter 80 % des 
services au coeur de votre metier. 

Synthese de la gestion proactive 

Cette partie a pour objectif de faire un recapitulatif sur la 
gestion proactive des problemes. 

Nous etablirons une synthese du fonctionnement du proces- 
sus proactif de la gestion des problemes ainsi que la fiche 
descriptive de chaque activite de ce processus. 

Nous apporterons des reponses aux questions suivantes : 

Quels objectifs ? Quels livrables ? Quels outils ? 

Quels moyens de mise en oeuvre ? 

Quel mode de suivi ? 

S3 

I 

Vous trouverez dans la figure ci-apres une vue synthetique du fonc- | 
tionnement de la gestion proactive des problemes : ° 
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problemes et 
des erreurs 
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Figure 5-4 : Boite << grise » de la gestion proactive des problemes 

Analyse des tendances 

Objectif de 
I’activite : 

Identifier les problemes recurrents et les problemes 
potentiels 

Quels outil / moyen : 

Rapport de la gestion d’incident, statistiques de la gestion de 
configuration, donnees historiques sur les incidents, analyse 
d’evenements issus de I’administration des systemes, de la 
gestion des alarmes, revue de groupe utilisateur, rapports 
generes par les logiciels. 

Quel livrable : 

Analyse et verification des hypotheses sur un domaine general 
de probleme qui requiert une vigilance. 

Identification des sources d’erreurs potentielles. 

Identification des elements de configuration faible sur le SI. 

Mode de suivi : 

Comite de suivi des problemes (pour surveillance et controle 
des problemes et des erreurs) et workflow (pour suivi au 
quotidien). 
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Initialisation des actions preventives 


Objectif de Identifier les actions en anticipation de defaillances 

I’activite : possibles 

Quels outil / moyen : 

Revue et documentation technique des materiels, des 
applicatifs, des logiciels. Veille technologique. 

Quel livrable : 

Emission d’une demande de changement. 

Mise en place de formations clients, utilisateurs, ou personnel 
interne a la DSI. 

Mode de suivi : 

Comite de suivi des problemes (pour surveillance et controle 
des problemes et des erreurs) et workflow (pour suivi au 
quotidien). 


Activite specifique d’apport d’information a l’organisation 


?activit6^ Faire des recommandations pour ameliorer le SI 

Quels outil / moyen : 

Relecture de document d’exploitation emis par le projet. 

Quel livrable : 

Apporter un retour d’experience. 

Revue d’information a I’intention de la direction. 

Mode de suivi : 

Comite de suivi des problemes (pour surveillance et controle 
des problemes et des erreurs) et workflow (pour suivi au 
quotidien). 


La gestion proactive des problemes n’a pas necessairement besoin 
d’etre systematiquement effectuee avec des ressources a temps plein. 
Pour les organisations plus petites ou dans le cas ou les ressources se 
font rares, cette activite peut etre organisee a intervalle de temps rela- 
tivement espace (tous les 6 mois par exemple). 

N’oubliez pas que ce qui compte n’est pas tant de traiter du volume, 
mais plutot de se concentrer sur le bon volume. L’experience 
confirme la loi de Pareto : 20 % des problemes causent 80 % des 
degradations de la qualite de service ! 


s 

1 


Chapitre 5 


Surveillance et suivi des problemes 
et des erreurs 


Cette partie a pour objectifde mettre en evidence une activite 
transversale a chacune des operations mises en oeuvre dans le 
cadre du processus de gestion des problemes. Il s’agit de l ’acti- 
vite de surveillance et de suivi des problemes et des erreurs. 

Nous preciserons les moyens permettant de mettre oeuvre ce 
type d’activites en repondant aux questions suivantes : 

Quel est Vobjectif de cette activite ? 

Comment Vorganiser et la mettre en place ? 

Quels sont les principes et bonnes pratiques a suivre ? 

Quel schema directeur adopter ? 

L’activite de surveillance et de suivi des problemes et des erreurs est 
importante pour le pilotage et la communication des actions mises en 
oeuvre dans le cadre du processus. Il s’agit d’une activite transversale 
a l’ensemble du processus, dont la vocation est de rendre le proces- 
sus operationnel au quotidien. 

• La surveillance des problemes se concentre sur le controle et le 
suivi des actions qui vont permettre d’operer la mutation d’un 
probleme en erreur connue. 

• La surveillance des erreurs se concentre sur le controle et le suivi 
des actions qui vont apporter une resolution structurelle des 
erreurs connues dans le systeme d’information. 
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Dans la pratique, cette activite pourra etre realisee au travers d’une 
reunion reguliere de suivi des problemes. Ce comite de suivi des 
Problemes (appelons-le CSP) va permettre d’etablir une revue de 
l’ensemble du portefeuille des problemes et des erreurs. 

Dans la pratique, il est preconise de penser l’organisation de ce 
comite en deux temps. 

Lors de la mise en place du processus : 

• Initialiser le portefeuille de problemes avec la mise en commun 
de l’ensemble des problemes issus de la capitalisation et de 
Pexperience des experts. 

• Valider les priorites attributes a chaque probleme. 

• Organiser l’enregistrement des problemes. 

• Convenir de l’organisation des groupes d’experts devant interve- 
ne sur le traitement des problemes. 

En phase de suivi : 

• Partager la liste des problemes enregistres et suivre de fagon 
recurrente l’avancement des problemes prioritaires, ainsi que les 
problemes dont Faction arrive a Fecheance definie au prealable. 

• Valider/arbitrer la priorite de traitement des nouveaux problemes 
ouverts en fonction de l’impact sur la qualite de service et/ou sur 
le cout occasionne a l’activite de Fentreprise. 

• Evaluer les risques d’escalade et acter les Groupes d’Intervention 
d’Experts (GIE) en charge du traitement des problemes. 

• Proceder a une revue des indicateurs de performance du proces- 
sus pour publication des resultats commentes. 

Ce comite de surveillance et de suivi des problemes et des erreurs n’a 
pas pour vocation de remplacer les efforts et les investissements qui 
doivent etre fournis au quotidien par le personnel d’assistance des 
problemes. La communication entre les experts et autres acteurs du 
processus est primordiale sur le terrain. Ce comite doit donner une 
vision de synthese. 

Les blocages operationnels doivent trouver une issue (en fonction de 
Fimpact sur Favancement des problemes et de la priorite associee) J 
avant le comite. Agissant neanmoins comme une tour de controle, 
cette activite doit permettre de remonter les besoins d’arbitrage et les | 
alertes vers le management. L’animation de cette reunion est sous la ° 
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responsabilite du gestionnaire des problemes. L’ensemble des 
experts necessaires devrait etre convie pour cette revue. 

Dans ce modele, le plan du comite de suivi des problemes peut se 
representer comme suit : 



Figure 6-1 : Surveillance et controle des problemes et des erreurs 

Cette instance de surveillance et de controle des problemes et des 
erreurs doit avoir en entree la qualification et la classification initiale 
des dossiers Problemes ouverts incluant done 1’evaluation de leur 
impact sur la qualite de service et/ou de l’impact sur les couts pour 
l’entreprise. 

Prevoyez en elements de sortie : 

• un compte rendu du comite ; 

• la validation de l’impact de chaque probleme et l’affectation d’une 
priorite partagee par l’ensemble des acteurs ; 

• la repartition des experts sur chaque dossier dans le cadre des 
Groupes d’Intervention d’Experts (GIE) definis et valides par 

I l’ensemble des acteurs durant le comite ; 

I • le tableau de bord d’activite mis a jour pour publication a 
| l’ensemble des parties au sein de l’organisation de la DSI. 
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La constitution des GIE (Groupe d’lntervention d’Experts) est une bonne 
pratique qui permet de federer I’expertise adequate. Sous la tutelle de I’activite 
de surveillance et de controle des problemes et des erreurs, pilotee par le 
gestionnaire des problemes, ce groupement est un facteur d’efficacite 
essentiel pour le deroulement des travaux entre experts. 


s 
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Chapitre 6 

Gestion des problemes majeurs 


Traitement des incidents majeurs 

Cette partie a pour objectifde decrire le mode operatoire uti- 
lise en gestion des incidents majeurs. 

Nous aborderons les modalites generates pour [’organisation 
et le traitement d’un incident majeur. 

Nous apporterons des reponses aux questions suivantes : 
Qu’est-ce qu’un incident majeur ? 

Comment le detecter suffisamment tot ? 

Comment le traiter ? 

Quel schema d’escalade existe-t-il entre un incident classique 
et un incident majeur ? Quelle organisation mettre en place ? 

Comment communiquer sur les incidents majeurs ? 

Dans la litterature ITIL, le chapitre sur les incidents majeurs est peu 
documents et que tout le chapitre sur le sujet est mis au conditionnel. 
Les incidents majeurs sont ceux pour lesquels le degre d’impact sur 
l’ensemble des utilisateurs est extreme. La methode ITIL preconise 
aussi de considerer comme majeurs, les incidents pour lesquels le 
degre de perturbations devient excessif au regard du temps de reso- 
ws lution (SLAs), meme si cela touche un petit nombre d’utilisateurs. 

Dans ce cas, la recommandation est d’avertir le gestionnaire de 
| problemes afin qu’il organise une reunion (ou plusieurs) avec toutes 
" les parties concernees : 
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• equipe de support interne ; 

• equipe de support des materiels/logiciels ; 

• equipe de gestion des services de la production. 

Sur la question des incidents majeurs, l’organisation des niveaux 
d’escalade entre la gestion des incidents et la gestion des problemes 
s’illustre comme suit : 


Gestion des crises 

1 

Niveau 3 

1 

Gestion des problemes 



.... 

Gestion des incidents 

V 

u 

Niveau 1 


Figure 7-1 : Les niveaux de gestion d’incidents 


Dans un contexte de gestion d’incidents majeurs ou de crise, il faut 
retenir plusieurs choses. 

Sur le plan strategique, les enjeux business sous-jacents sont au cceur 
de l’interet general jusqu’au plus haut de la de la hierarchie, c’est-a- 
dire la Direction Generate (DG). Les obligations legates de l’entre- 
prise vis-a-vis d’organismes externes et vis-a-vis des clients doivent 
etre securisees et pilotees. 

Sur le plan tactique, le besoin d’information et de pilotage monte 
d’un cran. Il est indispensable de tenir informe et de communiquer 
regulierement vers les instances de management au sein de la DSI. Le 
niveau de tragabilite necessaire s’accentue. Une extreme rigueur est 
done cruciale. 

Sur le plan operationnel, les actions a coordonner se complexifient 
(ne serait-ce que par le nombre d’intervenants necessaire). 

Pour toutes ces raisons, le traitement des incidents majeurs doit 
suivre un mode de gestion particulier. Le plus delicat consiste a defi- J 
nir les criteres d’eligibilite a la qualification d’incident majeur. Plus les |> 
criteres sont pertinents, plus vous augmentez vos chances de ne pas | 
avoir a traiter la situation en mode de crise. ° 
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Dans la pratique, un incident devrait etre considere comme majeur 
(et done potentiellement faire l’objet d’un traitement selon une 
procedure de gestion d’incident majeur, si : 

• L’incident affecte un service directement visible de vos clients 
finaux et si son traitement a depasse les delais correspondant aux 
exigences (Service Level Request) de vos clients internes (MOA 
pour Maitrise d’Ouvrage). 

• L’incident touche un service en support aux metiers et au pilotage 
de l’entreprise et si son traitement a depasse les delais correspon- 
dant a votre engagement de contrat de service (Service Level 
Agreement) signe avec vos clients internes. 

• L’incident a un retentissement mediatique fort (interne et/ou 
externe a l’entreprise). 

II est conseille de formaliser dans le cadre du contrat de service, la 
declinaison pertinente de ces criteres selon les caracteristiques des 
services associes. Des lors que l’incident majeur est declare, il 
convient d’ouvrir un dossier d’incident majeur et de gerer l’incident a 
hauteur des enjeux dans le cadre d’une cellule d’incident majeur. 
Cette gestion est du ressort de la gestion reactive des problemes. 



Releve des enjeux 


Releve de decision 


Releve des actions 


Business 


SI 


IT 


Figure 7-2 : Alignement du plan d’actions avec les enjeux de I’entreprise 
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L’alignement a observer pour la construction du plan d’actions de 
resolution de l’incident majeur devrait retenir la fougue des experts 
qui voudront rechercher le moyen de resoudre ce type d’incident et 
identifier clairement les enjeux auxquels. Cette vision vous permettra 
de structurer vos decisions et vos actions. 

La communication est une part primordiale du traitement des inci- 
dents, d’autant plus concernant les incidents majeurs. II est neces- 
saire de veiller a bien informer les clients, la direction, les acteurs de 
la cellule d’incident majeur, sans oublier le Centre de services (qui 
joue un role important dans ce cadre en tant que guichet unique de 
la DSI) et tout autre intervenant. Une bonne coordination de la 
communication fait gagner du temps dans les decisions a prendre et 
dans la mise en oeuvre des actions a engager. 

La communication sur un incident majeur doit integrer les 10 compo- 
santes suivantes : 


1 

Synthese Ce qu’il faut retenir 



2 

Bilan des impacts Synthese des impacts par ordre de priorite 


| Impact sur les clients finaux 

II. Perte de chiffre d’affaires 

III. Degats collateraux sur les systemes en support au 
pilotage de I’entreprise 

3 

Faits Dysfonctionnement horodate 



4 

Cause Origine du dysfonctionnement 



5 

Impacts Consequence du dysfonctionnement sur le 



6 

Enjeux Nombre de clients touches / perte de CA associee 



7 

Decision fonction de I’impact Decision pour mattriser les impacts 


Chantier A 1. Plan de route pour pallier la propagation des 

impacts 

Chantier B II. Plan de route pour sauvegarder les clients finaux 


.../... 
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Chantier C 

III. Plan de route pour sauvegarder le CA 


Chantier D 

IV. Plan de route pour reparation et correction 
definitive des systemes 

1 1 1 

8 

Plan d’actions 

Actions a engager par categorie / acteur / 
echeance cible 


Chantier A 

1 . Stopper I’hemorragie 


Chantier B 

II. Reparer le prejudice subi par les clients finaux 


Chantier C 

III. Plan de route pour sauvegarder le CA 


Chantier D 

IV. Remettre en conformite les systemes 
1 1 1 

9 

Avancement 

Suivi du plan d’actions 


1 1 1 

10 

Plan de communication 

Planification des instances de pilotage / 
nomination des responsables 


Instance 1 

Pilotage des decisions 


Instance II 

Pilotage du plan d’actions global 


Les differents chantiers operationnels ouverts pour traiter l’incident 
majeur devraient etre sous le controle et le pilotage global du 
gestionnaire des problemes. 

Deux types de communication institutionnelle sont a prevoir : 

• Une communication de niveau 1 vers l’ensemble des acteurs de la 
cellule d’incident majeur. Elle est redigee par le gestionnaire des 
problemes. 

• Une communication de niveau 2 vers le management (DSI et 
clients) en charge du pilotage des decisions. Selon les circonstan- 
ces, cette communication pourra etre prise en charge soit par le 
gestionnaire des problemes, soit par le management. 

Quelques reflexes et bonnes pratiques sont a observer durant la mise 
en oeuvre d’une cellule d’incident majeur. Ces points doivent etre 
sous le controle du gestionnaire des problemes qui prend en charge 
la coordination du plan d’actions global. 

I 

I 

o 

© 
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Toutes les traces doivent etre sauvegardees afin de proceder a une analyse 
ulterieure (dans le cadre de la revue des problemes majeurs) sur les 
circonstances aggravantes des impacts occasionnes ainsi que des 
responsabilites en cause, et du plan de fiabilisation a piloter pour garantir la 
non-reproductibilite de I’incident. 


Dans le cadre du traitement d’un incident majeur, il est conseille de faire 
intervenir un representant des clients qui va etre le correspondant des MOA au 
sein de la DSI et dans I’ensemble des structures MOA. Cela permet de federer 
les priorites dans un alignement partage et de renforcer la coherence des 
decisions prises dans I’interet premier de I’entreprise. 


Ne pas sous-estimer la valeur ajoutee du Centre de services dans le cadre de 
la cellule d’incident majeur. II est possible que d’autres incidents, en rapport 
avec I’incident majeur en cours de traitement, soient declares au Centre de 
services. II est done important d’y associer un membre du Centre de services 
afin qu’il puisse faire etat des appels regus pouvant etre en rapport avec 
I’incident majeur en cours. De la meme maniere, certaines informations issues 
de la cellule d’incident majeur auront tout interet a etre publiees depuis le 
Centre de services, lorsqu’il s’agira de diffuser des informations aux 
utmsateurs concernes de la DSI. Les acteurs du Centre de services auront 
egalement pour mission de s’assurer de la tragabilite de I’ensemble des 
actions menees dans le cadre de I’enregistrement de I’incident. 


Tous les experts necessaires doivent etre mobilises pour intervenir sur le 
traitement de I’incident majeur dans le cadre du pilotage de la gestion des 
problemes. Ce pilotage doit intervenir transversalement, avec le mandat exclusif 
de rapprocher les organisations, les departements et les structures vers I’objectif. 
Le gestionnaire des problemes devient le manager operationnel de I’ensemble 
des experts concernes pour le temps du traitement de I’incident majeur. 


Bien veiller a identifier des criteres de sortie d’incident majeur. Si I’etape la 
plus delicate est d’ouvrir la cellule d’incident majeur au bon moment, I’etape la 
plus difficile est bien souvent de revenir dans le cadre d’un dispositif de soutien 
regulier et conforme a I’exploitation. Une cellule d’incident majeur represente 
un cout non negligeable : mobilisation des competences de niveau superieur, j 

dispositif d’expertise en astreinte hors jour ouvres, tache d’exploitation 1 

specifique, presence physique sur site, etc.). II est done primordial d’identifier ’S 
lors de I’ouverture de la cellule d’incident majeur, les criteres de sa fermeture. | 
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Le tableau ci-dessous presente un modele de tableau de bord pour le 
suivi des actions. 

PLAN D'ACTIONS D’INCIDENT MAJEUR | 

Impacts Enjeux Decision Plan d’actions Pilotage des actions Echeance Statut 


Revue des proble m es majeurs 

Cette partie a pour objectif de presenter le dispositif de ges- 
tion et de revue des problemes majeurs. Il s’agit d’une com- 
posante mise en oeuvre dans le cadre du processus proactif 
de gestion des problemes. 

Nous tacherons de presenter concretement la fagon dont 
cette revue peut etre mise en place. 

Nous apporterons des reponses aux questions suivantes : 
Qu’est-ce que la revue des problemes majeurs ? 

Comment dejinir ce qu’est un probleme majeur ? 

Pourquoi instaurer un tel type de dispositif? 

Comment la gestion des incidents alimente-t-elle la revue des 
problemes majeurs ? 

La gestion des problemes majeurs est la gestion des problemes dediee 
aux incidents dont l’impact sur le service est extremement fort pour 
l’entreprise. Il est conseille de commencer par mettre en place ce 
dispositif avant d’aller plus loin dans la gestion reactive des problemes. 
Les incidents qui nuisent gravement aux affaires et/ou a l’image de 
l’entreprise font l’objet d’une instruction par la gestion des proble- 
mes, car ils necessitent la mise en place d’un plan d’actions qui va 
permettre d’eviter leur reproduction (on serait surpris d’imaginer le 
g contraire). 

j| Pour ce type d’incident, l’enjeu principal de la revue des problemes 
I majeurs porte sur la generalisation d’une analyse post-incident, ainsi 
| que sur la consolidation d’un plan d’amelioration permettant d’elimi- 
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ner les causes de non-QoS et d’ameliorer le delai de resolution, si les 
risques de reapparition de l’incident ne peuvent etre ecartes. 

Une veritable autopsie de l’incident sera operee pour rechercher les 
points de QoS perdus, et ce de la fagon la plus pragmatique qui soit. 
Voici un exemple d’articulation possible : 


Gestion des inddents 



Figure 7-3 : Organisation de la revue des problemes majeurs 


Flux n°l 
Flux n 2 
Flux n 3 
Flux n°4 
Flux n"5 


declenchement d’un Bureau d’Enquete Incidents (BEI). 
consolidation du plan d’actions d’amelioration QoS. 
alimentation du rapport a l’intention de la direction, 
alimentation/mise a jour des plans d’actions. 
alimentation/pilotage des plans d’actions. 


La decision de declencher un Bureau enquete incidents doit etre 
prise selon l’appreciation de criteres definis. Pour aider a la definition 
des criteres, nous pouvons observer une regie simple de categorisa- 
tion des services metiers selon 2 categories. 
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Categorie du 
service 

Types d’applications 

Exemples 

Categorie 1 

Applications au contact direct du 
client 

Facturation des services rendus 
aux clients 

Categorie 2 

Applications pour le support metier et 
pour le pilotage de I’entreprise 

Logiciel de paie, SI Fraude, SI 
Obligations legales 


Selon ces categories de services metiers, nous pouvons envisager 
trois criteres qui peuvent permettre d’instruire le declenchement d’un 
Bureau enquete incidents pour la revue des problemes majeurs : 

• incident avec impact sur un service de categorie 1 (significatif) ; 

• incident avec impact sur un service de categorie 2 dont le SLA est 
affecte ; 

• derive significative du traitement d’un incident quelle que soit la 
categorie du service affecte. 

Pour que le Bureau enquete incidents soit pertinent, il est necessaire 
d’identifier les elements d’entree qui vont 1’alimenter. Voici quelques 
elements essentiels pour l’efficacite de son analyse : 

• la qualification/classification initiale de l’incident (impact, niveau 
de severite, volumetrie, contexte d’incident) ; 

• la date et l’heure de declaration de l’incident, le n° des tickets 
d’incidents, etc. ; 

• le detail des actions menees pour chaque activite de la gestion 
d’un incident (cf. schema ci-dessous) ; 

• la consolidation du detail des actions menees pendant chacune 
des activites de la gestion de l’incident ; 

• la collecte des traces et historiques d’erreurs ; 

• l’extraction des alarmes et de tout evenement annonciateur du 
dysfonctionnement avec l’horodatage associe ; 

• l’extraction du ou des changements a l’origine de l’incident (si 
une telle correlation existe) ; 

• l’impression des documents d’exploitation (modes operatoires, 

g fiches de diagnostic, fiches de controle, fiches de tache d’exploita- 

| tion, fiches d’alarmes, etc.) appliques pendant la gestion de 

g, l’incident ; 

| • l’analyse technique des supports. 
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Le schema ci-dessous represente les interactions entre le Bureau 
enquete incidents et le processus de gestion des incidents : 


Detection Support initial Investigation Resolution 

et — ► et — ► et — ► et — ► Cloture 

enregistrement classification diagnostic retablissement 



« A chaud » 

Figure 7-4 : Interactions entre la gestion des incidents et la revue des 
problemes majeurs 

Pour chaque activite du processus de gestion des incidents, il faut se 
poser les questions initiates : « Est-ce normal ? Et pourquoi ? Les 
modes operatoires existants ont-ils ete appliques de fagon nominate ? » 

La revue des problemes majeurs va egalement s’interesser a 
comprendre ce qu’il s’est passe en evaluant les informations issues 
des 4 axes suivants pour chaque etape du processus : 

• Ce qui s’est fait correctement : il va s’agir d’identifier les bonnes 
pratiques a reproduire, a conserver, a referencer pour alimenter 
les efforts de centralisation de la connaissance (base de connais- 
sances). 

• Ce qui n’a pas ete fait correctement : cela consiste a identifier les 
points faibles a l’origine de la non-performance dans le cadre des 
operations engagees pour le retablissement du service. L’objectif 
est de reussir a mettre le doigt sur les difficultes rencontrees et les 
erreurs commises. La transparence des faits et le detail des infor- 
mations collectees sont essentiels pour (identification des leviers 
d’amelioration. 

• Ce qui pourrait etre mieux fait : il va s’agir d’identifier dans les J 
procedures, les bonnes pratiques qui peuvent etre optimisees ou Jj- 
revues. L’objectif etant d’ameliorer le fonctionnement ou l’utilisation | 
d’une base de capitalisation en integrant les complements d’infor- ° 


Ce qui n'a pas ete fait Ce qui a ete fait 
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mations pertinents issus de l’experience. Cette pratique doit permet- 
tre de raccourcir d’autant plus le delai de reaction pour la remise en 
etat du systeme en cas de reproduction de l’impact sur le service. 

Ce qui pourrait etre evite : on cherche a etablir le plan de fiabili- 
sation ou plus precisement le plan de non reproductibilite de la 
panne de service rencontree. L’objectif est d’identifier les axes de 
travaux permettant de garantir que l’impact de service occasionne 
ne se reproduira pas et de mettre en oeuvre ces axes de travaux 
sous la forme d’un plan d’actions defini et pilote par un gestion- 
naire. C’est aussi un acte de prevention. Dans ce cadre, toute 
faille potentielle du systeme pouvant faire encourir un risque sur 
la qualite de service doit etre ecartee par la mise en oeuvre de la 
recommandation adequate. 


Revue des problemes majeurs 

Detection et enregistrement : 

£ 1 - Avons-nous fait la correlation entre un incident par I'exploitation et un 

g incident impactant le (les) service(s) du client ? 

§ 2 - Les moyens de detection sont-ils suffisants ? 

^ Support initial et classification : 

t 3 - La classification de I'incident est-elle en coherence avec I'impact sur la QoS ? 
S 4 - La qualification de I'incident a-t-elle ete optimale ? 

Investigation et diagnostic : 

5 - Existe-t-il des fiches de taches pour traitement au 1 er niveau de support ? 

6 - Les fiches de taches peuvent-elles etre ameliorees ? 

7 - L'escalade vers les supports s'est-elle passee dans les meilleurs delais ? 

8 - Le contenu des logs est-il pertinent en terme d'exploitabilite ? 

9 - Avons-nous connaissance de la cause initiale ? 

10 - Avons-nous identifie la cause sous-jacente ? 

1 1 - Y a-t-il un lien avec un changement ? 

c 12 - Est-ce que ce type d'incident est rencontre pour la 1 re fois ? 

£ Resolution et retablissement : 

5 13 - Le mode operatoire de resolution applique durant la gestion de I'incident 

g est-il le plus efficace ? 

£ 14- Le rattrapage est-il outille (manuel, semi-manuel, industriel) ? 

u Cloture : 

15 - Avons-nous les moyens a I'exploitation pour verifier le retablissement de 

service ? 

16 - Le retablissement de service peut-il etre effectue par I'exploitation ? 



< p 
si 

$ 

8 a 



Figure 7-5 : Les questions essentielles en revue de probleme majeur 

Le BEI doit fournir les elements de sortie suivants : 

1. une description partagee du probleme ; 

2. un impact chiffre du probleme : 

I • impact sur les affaires de l’entreprise ; 

g, • impact client ; 

| 

g • perte de points en QoS ; 
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Figure 7-6 : Le schema directeur de la procedure de revue 
des problemes majeurs 

3. une analyse partagee de la chronologie des evenements incluant 
la mise en exergue des points durs et/ou a ameliorer ; 

4. une analyse de la cause racine ( root cause) : 

• description partagee de la cause sous-jacente ; 

• identification du ou des changements a l’origine de la cause ; 

5. un plan d’actions precis avec des dates d’echeance sur la mise en 
place de : 

• la solution de contournement : 

- redaction du mode operatoire applicable a l’incident sur 
chacune des phases (detection, qualification, diagnostic/inves- 
tigation, resolution/rattrapage) ; 

- gain estime en QoS par rapport a la solution de contourne- 
ment proposee ; 

• la solution definitive comportant deux scenarii de proposition de g 

solutions definitives, avec : 1 

- avantages, inconvenients, difficultes de mise en oeuvre ; §. 

- cout de la solution ; ° 
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- ROI (retour sur investissement), Business case (dossier 
d’analyse economique) ; 

- chiffrage de l’abondement financier necessaire. 

6. l’enregistrement des elements 1 a 5 dans l’outil de workflow de la 
gestion des problemes. 

La matrice des roles et responsabilites s’illustre comme suit, R signi- 
fiant Responsable et C Contributeur : 


Roles 

Gestion 

des 

incidents 

Responsable 
Centre de 
services 

Support 
niveau 2 

Support de 

niveau 3 

(MOE- 

maftre 

d’oeuvre, 

expert 

d’application, 

etc.) 

Informations et livrables 
attendus 


Centre de services / 
gestionnaire des incidents 

Gestionnaire des 
problemes 

Types d’actions et livrables 


R 




Qualification/Classification 
initiale de I’incident 
(impact, niveau de 
severite, volumetrie, 
contexte d’incident, date et 
heure de declaration, n' 
des tickets, etc.). 

3 

R 




Detail des actions menees 
par phase principale de la 
gestion d’un incident. 

■O 

! 

i 

R 



C 

Preparation de la 
consolidation de I’autopsie 
de la gestion de I’incident 
et de la chronologie de 
I’incident par phase du 
processus de gestion des 
incidents. 


R 


C 


Collecte des traces. 


R 




Extraction des alarmes. 


R 


C 


Extraction du changement 
(si une correlation existe 
avec un changement). 


R 




Impression des fiches de 
taches / f iches d’alarmes 
appliquees. 


R 




Elements d’informations 
sur la severite haute, 
I’impact client / technique, 
le risque engage par la 
non-maltrise du traitement 
de I’incident (en fonction 
du service). 
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!ii 


R 

C 


Elements d’information sur 
la categorie 1 du service 
affecte, I’impact sur le SLA 
et le risque engage par 
non-maltrise de I’incident. 




R 


Animation du BEI 


!> 

R 




Presentation du livrable 
consolide de I’autopsie de 
la gestion de I’incident et 
de la chronologie de 
I’incident par phase du 
processus GDI. 

f 

C 


R 

C 

Preparation du plan 
d’actions d’amelioration, 
de fiabilisation et de 
revaluation de la solution 
vs gain de qualite de 
service. 


}J 



R 


Consolidation du plan 
d’actions d’amelioration, 
de fiabilisation et de 
revaluation de la solution 
vs gain de qualite de 
service. 


Void des modeles de rapports du BEI : 


Date d’ouverture du BEI 
Description du probleme 


Phase de gestion de I’incident 

Incident survenu le : / 

Chrono de I’incident 


Revues des problemes majeurs - Bureaux d’enquetes incidents 


|n° d’incident 


Date de I’incident : _ 


0 Enregistrement 

Le / ./ a hh : mn 

0 Support initial et classification 
De _J_J _ hh : mn au _/ 
0 Investiation et diagnostic 
De _ hh : mn au _/ 
0 Resolution 


Commentaire 

Commentaire 

Commentaire 

Commentaire 

Commentaire 

Commentaire 

Commentaire 


Figure 7-7 : Fiche chronologique de la revue des problemes majeurs 
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Autopsie du processus gestion des incidents 

Resultats 

Oui/Non/SO 

O Detection et enregistrement 

© 

Avons-nous fait la correlation entre un incident detecte par I’exploitation et un 
incident impactant le (les) service(s) du client ? 

Non 

Les moyens de detection sont-ils suffisants ? 

Oui 

O Support initial et classification 

© 

La classification de I'incident est-elle en coherence avec I’impact sur la QoS ? 

Non 

La qualification de I’incident a-t-elle ete optimale ? 

Oui 

O Investigation et diagnostic 

© 

Existe-t-il des fiches de taches pour traitement au 1 er niveau de support ? 

Oui 

Les fiches de taches peuvent-elles etre ameliorees ? 

Non 

Lescalade vers les supports s’est-elle passee dans les meilleurs delais ? 

Oui 

Le contenu des logs est-il pertinent en terme d’exploitabilite ? 

Oui 

Avons-nous connaissance de la cause initiale ? 

Non 

Avons-nous identifie la cause sous-jacente ? 

Oui 

Line revue de I’historique des changements pouvant avoir un rapport avec 
I’incident a-t-elle ete effectuee ? 

Non 

Est-ce que ce type d’incident est rencontre pour la 1 re fois ? 

Non 

O Resolution et retablissement 

© 

Le mode operatoire de resolution applique durant la gestion de I’incident est-il 

Non 

le plus efficace ? 

Le rattrapage est-il outille (manuel, semi-manuel, industriel) ? 

Oui 

O Cloture 

© 

Avons-nous les moyens a I’exploitation pour verifier le retablissement de 

Oui 

service ? 

Oui 

Le retablissement de service peut-il etre effectue par I’exploitation ? 



Figure 7-8 : Restitution de la revue du probleme majeur 


Bilan des impacts 

Intitule du service impacte 


Impact client 


Impact business 


Perte de points de vie QoS 


Causes de non QoS 

Analyse de la root cause 








Figure 7-9 : Bilan des impacts et analyse de la cause racine (« root cause ») 


I A Tissue de la revue des problemes majeurs en BEI, deux types de 
| plans d’actions doivent etre definis. 
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Le premier est un plan d’actions de reduction du delai en cas de 
reproduction. II doit viser l’amelioration des delais sur chacune des 
etapes du processus qui se sont averees defaillantes en termes de 
performance apres l’autopsie de l’incident durant la revue de 
probleme majeur. Ce rapport peut suivre le modele ci-dessous : 



Date d’ouverture du 

, , | N °“ : 



Plan d’actions d’amelio 

ation du ddlai de resolution 

Phase degeetlentle 

iSe 

pr er 

d'Sns 

Avancement 

Priorite 

Porteur 

Eobeanoe 

a 



© 




Px 



Ouver, 

© 

S“ l6t 

© 




Px 



Ouver, 

© 

^SS° net 

© 




Px 



Ouver, 

© 

SSemt'n, 

© 




Px 



Ouver, 

© 

Cloture 

© - 




Px 


. 

Ouvert 

© 

Figure 7-10 : Modele de rapport du premier plan d’actions 

Le second plan d’actions concerne la non reproductibilite. 11 doit 
viser l’eradication de la cause racine du probleme majeur. Vous trou- 
verez ci-dessous un modele possible pour le rapport de ce deuxieme 
plan d’actions : 



Date d’ouverture du BEI 

“dent: 

Description du probleme 


Plan d'actions de non reproductibilite 



Plan d'actions 


Priorite 

Porteur 


a 








Px 




Ouvert 

© 




Px 



Ouvert 

© 




Px 



Ouvert 

© 




Px 



Ouvert 

© 




Px 


— 

Ouver, 

© 


s 

1 


Figure 7-11 : Modele de rapport du deuxieme plan d’actions 
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Le suivi de I’ensemble de ces actions doit etre pris en charge par le 
gestionnaire des problemes. Toutes les preconisations permettant de 
raccourcir le delai de resolution devront etre renseignees dans la base des 
erreurs connues, dans le cas ou le risque de reapparition de I’incident ne peut 
etre ecarte a 100 %. 

Veillez bien a ce que toutes ces informations soient systematiquement 
enregistrees dans la base des Problemes. 



Chapitre 7 

Roles et responsabilites 


POURQUOI DEFINIR LES ROLES ET RESPONSABILITES 

Cette partie a pour objectif de presenter la necessite de la 
mise en place des roles et responsabilites dans le cadre de la 
consolidation d’un processus. 

Nous presenterons egalement dans ce chapitre les actions 
devant etre cadrees dans la distribution des roles et respon- 
sabilites sur le processus de gestion des problemes. 

Nous apporterons des reponses aux questions suivantes : 

Quel type d’actions va-t-il falloir mettre en oeuvre pour les 
operations de chaque phase d’activite du processus de ges- 
tion des problemes ? 

Qui s’en charge ? 

Les roles et responsabilites sont bien souvent negliges lors de l’imple- 
mentation d’un processus, alors qu’il s’agit d’une etape de reflexion 
et de consolidation incontournable. 

Prenons l’exemple d’une entreprise qui met en place le processus 
gestion des problemes. Elle entreprend de cartographier les flux du 
processus en vision « boite blanche » (ou boite ouverte) pour en 
„ deduire les roles et responsabilites de chaque groupe de compe- 
1 tence. 


Le moment venu de la mise en place du processus, l’entreprise cons- 
tate que le partage des roles et responsabilites dans les faits n’est pas 
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si franc. Les activites sont executees par un groupe de competence 
ou un autre, de fagon croisee, sans homogeneite ni cadre precis. 

Les responsables de l’entreprise prennent alors du recul, et se disent 
qu’il ne serait pas opportun d’afficher des roles et des responsabilites 
partiellement representatifs de la maniere dont les acteurs travaillent 
dans leur quotidien au risque de heurter des sensibilites. Ils decident 
done en connaissance de cause de s’abstenir de presenter les roles et 
les responsabilites, avec la volonte de laisser champ libre aux bonnes 
pratiques en place et done a l’esprit d’autonomie des uns et des autres. 
Trois consequences sont a envisager suite a une telle decision : 

• Les acteurs devant travailler dans le processus ne vont pas savoir 
ce que Ton attend d’eux exactement. Leurs questions vont etre un 
reflet du flou de la comprehension generale . Et comme toute 
nouveaute fait peur... Ce flou est l’occasion revee pour justifier 
que la nouveaute que Ton souhaite ajouter dans leur activite n’est 
pas possible, ne marchera pas, etc. 

• Les acteurs devant travailler d’une fagon differente de celle corres- 
pondant a leurs habitudes vont entendre ce qui les arrange. Mais 
si tous les acteurs ne sont pas alignes sur une meme fagon de 
faire, l’echec du processus est inevitable. 

• Les acteurs devant travailler sur un sujet qui n’est pas vraiment au 
coeur de leur predilection habituelle, ou qui font simplement un 
rejet de base (la fameuse resistance au changement) vont adopter 
la posture de victime : « je ne sais pas comment il faut faire, qui 
fait quoi », etc. 

Vous l’aurez compris, la definition des roles et responsabilites est le 
coeur meme de la viabilite d’un processus, done mieux vaut s’y atte- 
ler des le depart, meme si elle est imparfaite. Il faut egalement rappe- 
ler que le processus lui-meme a intrinsequement besoin d’un niveau 
de clarte sur le « qui fait quoi » pour s’executer au quotidien. 

Vous trouverez ci-apres des exemples d’actions en lien avec le 
processus de gestion des problemes pour lesquels on aura associe 
role et responsabilite. 
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Exemples d’actions sur 1’ identification et l’enregistrement 
des problemes 


Comparer et associer 
les incidents 

Comparer les incidents avec la base de donnees des Problemes 
et des Erreurs connues pendant la phase de resolution de 
I’incident. 

Verifier I'existence d’incidents similaires et proposer I’ouverture 
d’un dossier Probleme a la gestion des problemes. 

Comparer les incidents qui n’ont pas deja ete rapproches avec 
les Problemes et les Erreurs connues, a partir de I’analyse des 
donnees de la base des incidents. 

Effectuer un premier rapprochement entre I’incident enregistre et 
la base des Erreurs connues et des Problemes. 

Associer les incidents qui sont de maniere evidente le resultat de 
I’enregistrement existant d’un probleme. 

Alerter et escalader 
la GDP 

Informer le gestionnaire de problemes de I’existence de 
nouveaux problemes. 

Escalader I’incident au porteur de la gestion de problemes en cas 
de divergence d’opinion ou d’autres moyens de resolutions 
possibles a rechercher. 

Informer/alerter sur les incidents majeurs (risque de crise). 

Solliciter le gestionnaire de problemes en cas de contournement 
d’un incident entralnant des couts ou des delais de traitement 
prohibitifs. 

Alerter la gestion de problemes sur les incidents significatifs 
(impacts sur la QoS et/ou Satcli - Satisfaction Client) dont la 
solution de contournement est inconnue. 

Qualifier/valider 
I’alerte issue du 
processus gestion 
des incidents vers la 
gestion des 
problemes 

Prendre en compte les escalades de I’equipe de gestion des 
incidents en cas de divergence d’opinion. 

Effectuer une revue des incidents associes par le Centre de 
services comme etant le resultat de I’enregistrement existant d'un 
probleme. 

Prendre en compte les demandes de support aux incidents 
majeurs sur declenchement du Centre de services et y associer 
I’enregistrement d’un probleme. 

Prendre en compte les sollicitations du Centre de services pour 
I’enregistrement d’un probleme en cas de contournement d’un 
incident entralnant des couts ou des delais de traitement 
prohibitifs. 

Analyser/verifier la 
base Incidents 

Analyser les donnees detaillees de la base Incident afin de 
reveler des incidents recurrents. 

Identifier les problemes lorsque la comparaison des incidents 
avec les Problemes et les Erreurs faites n’a pas ete concluante 
pendant la phase d’assistance initiale et de classement des 
incidents. 
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Enregistrer les 
problemes 

Enregistrer les problemes susceptibles de generer un impact fort 
pour les utilisateurs. 

Enregistrer les problemes inherents a la survenue de plusieurs 
incidents presentant les memes symptomes dans la base des 
Problemes. 

Remonter les 
reserves observees 
pendant les phases 
de tests sur les 
plates-formes de 
developpement de 
services 

Remonter les reserves en matiere d'exploitabilite. 

Consulter les 
rapports logiciels/ 
Produits 

Remonter les erreurs ou non erreurs anormalement observees 
dans les historiques. 

Alerter sur les 
bogues des logiciels, 
les fiches devolution 
ou les expressions 
de besoin mis au jour 
suite a des 
investigations sur les 
incidents 

Informer la gestion des problemes en production en cas de 
detection de non-conformite ou d’extension de besoin detectees 
lors d’un incident. 

Alerter suite aux 
analyses de la 
performance des 
composants IT et de 
I’infrastructure IT 

Alerter la gestion des incidents en cas d’observation de 
degradation sur la performance, I’accessibilite, le debit, la 
capacite de stockage, et tout autre evenement pouvant affecter la 
QoS Metiers. 

Alerter sur les points 
de frag i life detectes 
lors des phases de 
tests 

Prevenir/informer la gestion des incidents et la gestion des 
problemes des environnements de production de services, des 
bugs observes lors des tests. 

Alerter sur les 
tendances a risque 
de non tenue du SLA 

Alerter la gestion d’incidents en cas de risque de non-tenue de 
I’engagement du service convenu. 

Declarer un probleme 

Escalader la gestion de problemes en cas d’evenement pouvant 
etre un probleme. 

Valider le motif de 
refus d’un probleme 

Acter la non-pertinence de la declaration d’un probleme propose 
au rejet par la gestion de problemes. 

Convenir de plages 
de duree prolongee 
d’investigations GDP 
pendant des 
incidents 

Negocier avec le client une plage de maintenance exceptionnelle 
pendant la duree de I’incident, afin d’obtenir des informations qui 
aideront a la gestion de problemes et en informer la gestion des 
incidents. 
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Exemples d’actions sur le classement des problemes 


Prendre en compte 
les recommandations 
/conseils de la GDP 

S’assurer de la prise en compte des conseils, remarques, 
methodes, pratiques, consignes et recommandations emis par la 
gestion de problemes pour leur application lors d'incidents du 
meme type. 

Evaluer/Reevaluer 
I’impact et I’urgence 
d’un probleme 

Determiner le degre d’urgence d’un probleme sur la base de 
criteres comme la possibility de delais planifies de resolution, 
I’impact futur sur I’entreprise... 

Reevaluer I’impact et I’urgence du probleme en fonction du 
nombre d'incidents consecutifs lui etant attribue durant son cycle 
de vie. 

Verifier la pertinence 
de la solution de 
contournement 
apportee par la 
gestion des incidents 

Analyser I’historique des actions mises en oeuvre par la gestion 
des incidents pour resoudre la panne de service et s’assurer de 
I’etficacite de ces actions et de leur deroulement. 

Mettre a jour la base 
des problemes avec 
les 

1 res recommandation 
s pour la gestion des 
incidents 

Signaler toutes les informations pouvant aider a la resolution d’un 
incident (1 res recommandations). 

Mettre a jour la base 
des Problemes avec 
les 

1 res recommandation 
s pour la gestion des 
incidents 

Donner des conseils de resolutions possibles pour les incidents 
courants ou quand un Probleme ou une Erreur connue 
correspond. 

Hierarchiser les 
problemes 

Determiner la priorite de traitement a donner aux problemes en 
fonction de I’importance des impacts occasionnes sur I’entreprise, 
de I’urgence de traitement et conformement aux niveaux de 
services convenus. 

Faire une revue des 
problemes ouverts et 
valider la 

hierarchisation des 
problemes 

S’assurer de la pertinence de I’indice de priorite des problemes 
enregistres tel que fixe par la gestion des problemes en 
s’assurant de la coherence avec I’attente du client (Satcli) et avec 
I’engagement de qualite de service. 

Prendre en compte la 
hierarchisation des 
problemes 

Tenir compte de la priorite accordee aux problemes. 

Arbitrer la priorite et 
decider sur les 
investissements 

Prendre les decisions en cas de conflit sur la priorite a donner au 
traitement d’un ou plusieurs problemes et/ou de blocages dus a 
un manque de moyen (competences, financement). 

(Re)Categoriser les 
problemes en groupe 
ou domaine 
approprie 

Categoriser les problemes en groupe ou domaines apparentes. 
Exemple : materiel, logiciel, logiciel de support, categorie hors Cl 
(erreur humaine, erreur de procedure). 

(Re)Categoriser les problemes en groupe ou domaine apparente 
en fonction des elements apparus lors des investigations pour la 
recherche de la cause. 

Assigner le groupe 
support gestion des 
problemes 

Organiser le groupe de support en gestion de problemes. 
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Exemples d’actions sur 1’ investigation et le diagnostic 
des problemes 



Analyser le detail des elements Cl signales comme cause initiale 
par la gestion des incidents. 


Consulter les enregistrements des RFC (demandes de 
changement) relatifs aux Cl signales comme cause initiale par la 
gestion des incidents. 


Analyser les solutions de contournement appliquees par la 
gestion des incidents. 

Rechercher la cause 

Analyser la relation entre le probleme et les composants de 
I’infrastructure informatique enregistres dans la CMDB. 


Mettre en oeuvre les methodes d’analyse et de diagnostic des 
problemes (Kepner etTregoe, diagramme d’lshikawa, reunion de 
brainstorming). 


Consulter et tenir a jour la base de connaissances (logiciel 
expert). 


Analyser la non-applicabilite d’une solution de contournement 
prealablement validee comme possible et pertinente pour la 
gestion des incidents. 

Mettre a jour la base 
des problemes avec 
le rapport d’analyse 
sur la recherche de la 
cause du support 
d’expertise 

S’assurer de la tragabilite de toutes les investigations menees 
dans le cadre de la recherche de la cause ainsi que de la 
documentation associee. 

Referencer les bugs 
logiciels de non- 
conformity par 
rapport aux 
specifications de 
developpement 

Declarer une anomalie en cas de non-respect, par le systeme, 
d’une exigence prevue ou specifiee par un contrat. 

Mettre a jour la base 
des Problemes avec 
la reference de la 
non-conformite 

S’assurer de la mise a jour de la base des Problemes en faisant 
reference au numero d’anomalie ouvert pour non-respect des 
exigences specifies, et associe au probleme ouvert. 

Specifier le besoin de 
support d’expertise 

Identifier le type de competences necessaires pour la poursuite 
des investigations de la cause des problemes. 

Prendre en compte 
les donnees propres 
aux anomalies 
ouvertes et mises a 
jour dans la base des 
Problemes 

S’informer de I’ouverture de toute anomalie ouverte dans le cadre 
des investigations sur les problemes ouverts. 

Prendre en compte le 
refus motive de la 
demande d’expertise 

S’assurer de la prise en compte de I’analyse critique effectuee par 
le Support superieur concernant la demande de Support 
exprimee. 
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Informer la gestion 
des niveaux de 
services de 
I’avancement de la 
resolution des 
anomalies 

Assurer la communication aupres des Responsables Services 
Clients sur I'avancement de la resolution de toute anomalie 
abaissant ou risquant d’abaisser la QoS. 

Controler 
I’avancement de la 
resolution des 
anomalies abaissant 
la QoS 

Piloter les anomalies touchant la QoS (date de correction), relever 
le challenge des delais de resolution, gerer les priorites en 
fonction du gain QoS. 

Controler et suivre 
I’avancement des 
investigations sur les 
problemes 

Piloter I’avancement des problemes ouverts sur son portefeuille 
de services a I’aide d’indicateurs d’activite (delai de traitement, 
nombre de problemes ouverts, nombre de problemes rejetes, 
etc.). 

Rechercher la 
solution provisoire 

Etudier la meilleure solution possible permettant de limiter et/ou 
de sauvegarder la continuity de la qualite de service en priorite. 

Enregistrer la 
proposition de 
solution provisoire 
dans la base des 
Problemes 

Assurer le referencement et la tragabilite des informations de la 
solution provisoire mise en place. 

Specifier le besoin de 
moyens 

supplementaires (vs 
gain en QoS) et 
analyser les risques 

Identifier le type de competences necessaires pour la poursuite 
des investigations sur la recherche de solution provisoire. 

Arbitrer sur les 
besoins de support 

Prendre les decisions en cas de conflit sur la priorite a donner au 
traitement d’un ou plusieurs problemes et/ou de blocages dus a 
un manque de moyen (competences, financement). 

Mettre a jour la base 
des Erreurs Connues 

Enregistrer les solutions de contournement ou corrections 
temporaires dans la base des Problemes pour tout probleme 
identifie par un ou plusieurs incidents. 

Documenter la solution de resolution des incidents dans I’objectif 
que le support de niveau 1 soit autonome dans I’application de la 
solution. 

Fournir au Centre de services des instructions et des conseils sur 
les solutions de contournement possibles en prevention 
d’incidents pouvant survenir. 
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Exemples d’actions sur la resolution et la cloture des problemes 


Formaliser la 
solution provisoire 
dans I’outil de 
workflow 

Tracer le detail de la solution provisoire mise en oeuvre dans la 
base des Problemes. 

Formaliser une 
demande de 
changement si le SI 
est modifie 

Rediger une demande de changement pour I'implementation des 
solutions provisoires representant un ajout, une modification ou 
une suppression d’un element de configuration du systeme 
d’information. 

Formaliser une fiche 
de taches ou un 
mode operatoire pour 
le Support niveau 1 

Rediger une documentation permettant de capitaliser les actions 
pouvant etre executees par la gestion des incidents. 

Controler le 
deroulement de 
I’implementation du 
changement 

S’assurer de la bonne implementation du changement devant 
mettre en oeuvre la solution provisoire. 

Clore le probleme sur 
reception du compte 
rendu du 
changement 

Clore administrativement le dossier probleme dans le workflow de 
gestion des problemes des la mise en oeuvre de I’implementation 
de la solution provisoire (sous reserve de la fin de la periode 
d’observation definie). 


Exemples d’actions sur l’identification et l’enregistrement 
des erreurs 


Enregistrer I’erreur 

Enregistrer les erreurs des lors que le Cl incorrect (un Cl qui 
cause ou peut causer un ou des incidents) est detecte. 

Referencer et 
enregistrer les fiches 
de taches ou modes 
operatoires 

Enregistrer les documents permettant de capitaliser les actions 
pouvant etre executees par la gestion des incidents dans la base 
des Erreurs connues. 

Prendre en compte la 
fiche de tache ou le 
mode operatoire 
preconises par la 
GDP 

Utiliser les documents de capitalisation sur les actions a executer 
pour la resolution des incidents, mis a disposition dans la base 
des Erreurs connues. 


Exemples d’actions sur revaluation des erreurs 


Rechercher la 
solution definitive 

Etudier la meilleure solution possible permettant d’eradiquer les 
incidents et de traiter definitivement la cause premiere. 

Enregistrer la 
proposition de 
solution definitive 
dans la base des 
Problemes 

Assurer le referencement et la tragabilite des informations 
concernant la mise en place de la solution definitive. 

Specifier le besoin de 
support 

Identifier le type de competences necessaires pour la poursuite 
des investigations sur la recherche de solution aux problemes. 
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Specifier le besoin de 
moyens 

supplementaires (vs 
gain en QoS) et 
analyser les risques 

Identifier le type de competences necessaires pour la poursuite 
des investigations sur la recherche de solution aux problemes. 

Arbitrer sur les 
besoins de support 

Prendre les decisions en cas de conflit sur la priorite a donner au 
traitement d’un ou plusieurs problemes et/ou de blocages dus a 
un manque de moyen (competences, financement). 

Evaluer la faisabilite 
et le delai de la mise 
en oeuvre de la 
solution 

Participer a la selection des investissements justifies pour la 
resolution des problemes. 

Specifier les besoins 
de moyen (vs gain en 
QoS) et analyser les 
risques sur le service 
regulier 

Instruire le dossier de demande de moyen supplemental en 
mettant en perspective les risques, le gain et le cout. 

Evaluer les impacts 
de mise en oeuvre sur 
le service regulier 

Faire une analyse d’impact pour evaluer la meilleure planification 
possible pour implementation de la solution (cf. contrat de 
service). 

Tester la solution 
trouvee sur les 
environnements de 
test 

Proceder a une evaluation detaillee des actions de resolution a 
appliquer, la modification de I'element de configuration (Cl) errone 
et le test du changement. 

Valider revaluation 
des impacts de la 
mise en oeuvre sur 
les solutions aux 
problemes 

S’assurer et etre le garant de la mesure exhaustive des impacts 
clients sur son portefeuille de services et sur les services 
connexes. 

Arbitrer sur les 
investissements 

Prendre les decisions majeures en cas de blocage du a un 
manque de moyen (competences, financement). 

Abandonner la mise 
en oeuvre de la 
solution definitive du 
probleme 

Decider du non-traitement d'un probleme ouvert. 


Exemples d’actions sur l’enregistrement de la resolution 
des erreurs 


Enregistrer le mode Inclure I’identification (ID) d'enregistrement de la demande de 
operatoire de la changement aux donnees de I’Erreur connue et vice versa. 

solution trouvee 


Erreurs connues 
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Declarer un 
changement pour 
proposer le mode 
operatoire de la 
solution ainsi que sa 
planification 

Lever une demande de changement en accord avec le processus 
de gestion des changements. 

Demander I’autorisation a la gestion des changements pour la 
levee d’une RFC en urgence. 

Donner la priorite a la demande de changement en fonction de 
I’impact et de I’urgence de I’erreur sur I’entreprise. 

Emettre une 
demande de 
changement pour 
proposer le mode 
operatoire de la 
solution ainsi que sa 
planification 

Lever une demande de changement en accord avec le processus 
de gestion des changements. 

Demander I’autorisation a la gestion des changements pour la 
levee d’une RFC en urgence. 


Exemples d’actions sur la cloture de l’erreur et du (ou des) 
probleme(s) associe(s) 


Prendre en compte la 
validation de la 
gestion des 
changements suite a 
demande de 
changement emise 

S’assurer de la validation systematique des changements emis 
dans le cadre de la resolution des problemes aupres de la gestion 
des changements et conformement a la procedure existante. 

Consulter et se tenir 
informe de 
I’avancement de la 
realisation de la 
solution instruite 

Gerer/surveiller les processus impliques dans la progression des 
Erreurs connues jusqu’a ce qu’elles soient eliminees avec succes 
par la mise en oeuvre d’un changement (si cela est economique). 

Prendre en compte le 
rapport de fin de la 
RFC 

S’assurer du resultat du changement emis pour resolution des 
problemes par le bilan emis dans le cadre du rapport de fin de 
realisation du changement diffuse par la gestion des 
changements. 

Proposer la periode 
de mise sous 
observation de la 
resolution du 
probleme 

Identifier un temps de surveillance de la solution durant lequel 
sera confirmee sa pertinence. 

Valider la periode de 
mise sous 
observation de la 
resolution des 
problemes 

Acter la periode d’observation durant laquelle la solution est sous 
surveillance afin de confirmer sa pertinence (ou I’optimisation du 
mode operatoire de resolution d’incidents d’un meme type). 

Verifier la resolution 
du probleme pendant 

observation 

S’assurer de la pertinence de la solution de contournement ou de 
la solution definitive pendant un temps de surveillance predefini. 

Valider la cloture du 
probleme 

Acter la fermeture des problemes. 


Chapitre 8 

Implementation du processus 


Recommandations d’implementation 

Cette partie a pour objectifde presenter les principes a suivre 
pour la mise en place du processus de gestion des problemes. 

Nous apporterons des reponses aux questions suivantes : 

Quel est l’ agenda preconise pour la mise en place du 
processus ? 

Quelles sont les precautions a observer pour mettre en place ce 
processus ? 

Si la philosophic du processus de la gestion des problemes est 
simple et a la portee de tous, 1 ’implementation de ce processus n’en 
est pas pour autant aisee. Nous l’avons dit plus haut : il s’agit d’un 
plan de transformation qu’il faut accompagner avec le plus grand 
soin, les ecueils etant vite arrives. 

Dans votre organisation, vous pratiquez peut-etre deja la gestion de 
problemes sans le savoir (j’entends par la, le « savoir ITIL »). Ne sous- 
estimez pas pour autant les efforts de conduite du changement qu’il 
va falloir mettre en place. Bien souvent, lorsqu’on s’apenjoit que Ton 
experimente deja des elements d’un referentiel de bonnes pratiques, 
on pense n’avoir plus grand-chose a apprendre des bonnes pratiques 
en question. C’est l’erreur a ne pas commettre. 

A force de se repeter que « la gestion des problemes est deja integree 
dans le quotidien », l’organisation n’encourage pas la remise en cause 
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des acquis et la demarche de progres. II ne faut pas minimiser un 
changement surtout quand il s’agit de methode. 

Chacun est sensible a ce qui modifie meme un tant soit peu son 
quotidien. Dire qu’un changement n’est pas si important que cela, car 
ce que Ton souhaite apporter par ce changement est deja fait, revient 
a dire aux acteurs de ne rien changer du tout. 

Cela etant, il faut tout de meme veiller a ne pas en faire trop non 
plus. Certaines organisations entrent dans une mutation extraordi- 
naire qui bouscule toute les habitudes et memes les bonnes parce 
qu’elles veulent coller a la definition du processus decrite par ITIL. 
Dans le cadre du deployment du processus de gestion des proble- 
mes, il va falloir refreiner quelques ardeurs, quelques passionnes, et 
veiller a rester dans le pragmatisme. 

Tout d’abord avant de deployer ce processus, il est preferable d’avoir 
deja mis en place : 

1. le Centre de services ; 

2. la gestion des incidents prise en charge par le Centre de services ; 

3. la gestion des changements. 

La mise en place de la gestion des configurations n’est pas indispen- 
sable a la reussite de la mise en place du processus de gestion des 
problemes. Le processus de gestion des configurations etant au 
centre du programme ITIL, bien souvent les DSI sont tentees de se 
lancer dans l’aventure de la mise en place de ce processus en 
premier (parfois meme avant la mise en place de la gestion des inci- 
dents et du Centre de services). 

Il faut rester conscient que le processus de la gestion des configura- 
tions et sa fameuse CMDB (Configuration Management Data Base) 
necessitent une maturite forte de l’organisation dans la connaissance 
de ces composants informatiques et, qui plus est, imposent de bien 
connaitre son besoin en matiere de referencement des elements de 
configurations. Il n’est pas necessaire d’avoir une CMDB pour 
commencer a mettre en place les processus de soutien pour le 
service a fournir a vos clients. 

Le planning preconise pour le deployment du processus de gestion 
des problemes est decrit en Figure 9.1. 
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Agenda preconise Phase I Phase 2 Phase 3 Phase 4 


Pre-requis 

Reactive 

Proactif 

Reactif 

Proactif 

Gestion des 
incidents 
Gestion des 
changements 

1 

Mise en place du 
traitement des 
incidents majeurs i 

Mise en place de la 
„ revue des problemes 
majeurs 

Mise en place de la 
gestion reactive /- 
des problemes i 

39 

Mise en place de la 
-^gestion proactive 
des problemes 


V 

V 

V 



1' r couple 2' couple 


Figure 9.1 : Agenda de deployment du processus de gestion des problemes 

Plusieurs DSI auront echoue dans la mise en place du processus de 
gestion des problemes (ou dans une autre d’ailleurs) a cause d’un 
formalisme pousse a l’extreme sur les modes operatoires et les proce- 
dures qu’elles auront generes pour mettre en oeuvre ce changement. 
Dites-vous bien qu’une procedure qui fait plus d’une page a de bonnes 
chances de ne jamais etre lue et qu’un e-mail detaille sur la methode 
n’est pas une communication et encore moins une procedure. 

Pour distiller les nouveaux gestes dans les pratiques de vos equipes, 
il est necessaire de garder un bon equilibre entre la formation prag- 
matique et quotidienne et le laisser-faire, car cela reste le meilleur 
moyen d’integrer la connaissance. Il ne faut pas tomber dans le 
dogmatisme : 

• « ITIL dit que, done e’est cela qu’il faut faire ». 

• « ITIL represente le processus tel que, done e’est comme cela qu’il 
faut le faire ». 

• « ITIL ne dit pas, done cela veut dire que la question ne se pose pas ». 
Si le vocabulaire que vous utilisez en interne permet aux acteurs de 
se comprendre, il est inutile d’aller le changer contre un vocabulaire 
ITIL, simplement dans l’idee d’adopter une nouvelle terminologie 
sous le pretexte qu’elle est estampillee ITIL. 

Veillez a prendre en compte l’existant. Interviewez et auditez les 
acteurs sur ce qu’ils font, comment ils le font, avec quoi, avec qui. 
Vous apprendrez du terrain, et surtout vous saurez ce qu’il manque a 
votre organisation pour optimiser son processus de gestion des 
« problemes : ce sera la cle du succes. 

| Enfin, assurez-vous que les objectifs fixes repondent aux besoins de 
| l’entreprise. Devenir une production de services ne vise pas du tout 
| le meme objectif que devenir niveau 5 de tous les processus ITIL. 
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Deux conseils sont a suivre : 

• Confiez le deployment a une equipe rattachee a la DSI (de prefe- 
rence certifiee ITIL), avec des relais forts au sein de chaque popu- 
lation de la DSI. 

• Pensez a surestimer au moins d’un tiers le temps necessaire pour 
l’implementation du processus. La culture de toute entreprise est 
evolutive, mais il faut lui accorder du temps pour engager et assi- 
miler les changements d’organisation necessaires. 

L’informatique d’une grande entreprise est bien souvent un mi ll e- 
feuille organisationnel saupoudre de couches technologiques qui vien- 
nent s’ajouter les unes aux autres au fil du temps. Le fondement meme 
d’un processus est de gommer la notion de couche et de silo afin 
d’aligner l’ensemble des acteurs de l’organisation sur un meme objectif 
et ce, quels que soient leur departement, leur structure ou leur service. 

La vraie difficulty reside dans la conduite du changement plus que 
dans la description de tel ou tel aspect du processus. Cela plaide 
encore pour ne pas entrer dans le formalisme excessif en pensant 
que la cle de la reussite passe par la. 

L’important est de s’assurer au quotidien que les nouveaux principes 
sont adoptes sur le terrain et que les nouvelles procedures sont 
connues et appliquees par ceux qui font (et non ceux qui les ecri- 
vent). C’est justement le point qui fache : de nombreuses DSI investis- 
sent a corps perdu dans des outils de workflow, d’aide au diagnostic 
ou de design des processus en pensant que le changement s’operera 
a l’aide de ces moyens. C’est un vrai plaisir pour les consultants, mais 
ce n’est pas la voie par laquelle le changement va s’operer au sein 
meme de l’organisation. On peut disposer du meilleur outil de gestion 
des problemes sans pour autant pratiquer la gestion des problemes de 
la meilleure fagon qui soit (l’outil n’est pas tout). 

Reussir la mise en oeuvre de tout processus, c’est reussir une reelle 
remise en cause (meme dans les habitudes du management) et 
maftriser la connaissance des pratiques en place. Cela passe par un 
reel investissement sur l’accompagnement du changement. Ne nous 
voilons pas la face : la resistance au changement est monnaie 
courante dans le cadre de l’implementation des processus. La remise J 
en cause est un exercice qui ne met pas obligatoirement tout le 
monde a l’aise car vous allez etre amene a modifier les perimetres de | 
responsabilites qui s’etaient installes au fil des annees. ® 
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Cette remise en cause est toutefois un passage oblige pour bien iden- 
tifier les manques et les besoins d’ameliorations. Elle s’inscrit dans 
l’esprit de la roue de Deming (voir la figure 9.2) : integrer les phases 
de verification et d’optimisation dans l’activite recurrente. 


Amelioration 
de la quality 



Le Cercle de Qualite de Deming (annees 1930) 


Figure 9.2 : La roue de Deming 

« Plan » (planifier) : il s’agit de definir les objectifs a atteindre et de 
planifier la mise en oeuvre d’actions. 

« Do » (mettre en place) : cette etape correspond a la mise en oeuvre 
des actions correctives. 

« Check » (controler) : cette phase consiste a verifier l’atteinte des 
objectifs fixes. 

« Act » (agir) : en fonction des resultats de la phase precedente, il 
convient de prendre des mesures preventives. 

La demarche qualite joue un role preponderant dans la conduite du 
changement et done dans la reussite de l’implementation du proces- 
sus de gestion des problemes. Cela est d’ailleurs valable pour tout 
processus. L’amelioration continue est sous-jacente a un objectif 
general de management. 

Les axes de cette amelioration continue se distinguent selon quatre 
categories generiques qui permettent de donner du sens, en cohe- 
rence avec la strategic a adopter : 

1. Efficacite : on attend avant tout un meilleur fonctionnement du 
processus, en particulier par la reduction de la duree de son cycle 
d’execution et par la qualite des livrables de sortie. 
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2. Relation Client : au-dela de la rapidite du processus, il va s’agir 
principalement d’ameliorer sa qualite perdue par le client pour 
ameliorer la satisfaction de celui-ci. 

3. Efficience : l’objectif majeur est ici la reduction des couts. 

4. Flexibility : on cherche surtout a obtenir un systeme souple pou- 
vant etre modifie rapidement en cas devolution des contraintes 
et/ou de la strategic. 

L’amelioration continue est une sorte de quadrilatere diabolique. 



Une plus grande efficacite entraine la diminution de la flexibility et 
done une rigidite accrue. L’amelioration de la relation client engage 
une diminution de l’efficience, et inversement, une focalisation sur 
Poptimisation de Pefficience et done sur la reduction des couts peut 
se realiser au detriment de la relation au client (et de l’efficacite et de 
la flexibility). Et enfin, l’augmentation de la flexibility est souvent 
couteuse et risque de compromettre la recherche d’efficacite. 

En resume, pour s’approprier l’implementation du processus gestion 
des problemes, il va falloir miser sur les capacites d’un management 
du changement a la hauteur de votre ambition. 

Apres diverses experiences concernant la mise en oeuvre du proces- 
sus de gestion des problemes, je vous livre ici quelques reflexions et 
conseils. 

Lors de la mise en place de ce processus, on peut se poser la ques- g 
tion s’il preferable de proceder par petits pas ou de tout dynamiter. 1 
Le processus de gestion des problemes est la base pour l’ameliora- | 
tion de la qualite de service. Il s’agit neanmoins d’un processus qui a ° 


Implementation du processus 175 


besoin d’autres processus pour etre pleinement efficace dans 
l’atteinte de ces objectifs. II est done conseille d’avoir deja en place 
les processus de gestion des incidents, de gestion des changements 
et la fonction de Centre de services au moment de l’implementation 
du processus de gestion des problemes. Ce dernier fait interagir de 
nombreux intervenants dans l’organisation de la DSI (Centre de servi- 
ces, gestion des changements, support de niveau 2 et de niveau 3, 
maitrise d’oeuvre, architecte technique et hebergeur) qui ont besoin 
de temps pour apprendre a travailler ensemble. 

Le changement n’est pas instantane et ce n’est pas parce que les 
choses sont dites et ecrites qu’elles se realisent dans le meme temps 
sur le terrain. 11 est done important de prendre en compte la dimen- 
sion humaine et culturelle de l’environnement dans le cadre de l’arri- 
vee d’un tel processus, qui obligatoirement represente une revolution 
dans les habitudes de certains et une reelle evolution de fonctionne- 
ment pour la DSI tout entiere. 

Le management de l’ensemble de la DSI doit etre le moteur car 
l’enjeu organisationnel doit etre suivi de pres sur un plan hierarchi- 
que. La ligne directrice du deployment doit etre regulierement veri- 
fiee, controlee et adaptee par rapport au contexte et au potentiel de 
flexibility existant dans l’organisation. 

Si un certain niveau de formalisme (description des roles et responsa- 
bilites, des procedures de fonctionnement, des modes operatoires, 
etc.) est necessaire, il ne faut tomber ni dans l’exces, ni dans 
l’absence de formalisme dans la relation entre les differents acteurs 
qui vont avoir a travailler ensemble dans ce processus. 

Un trop-plein de procedures donne une image administrative du 
processus. Vous aurez toutes les difficultes du monde a faire adherer 
les acteurs du processus de la gestion des problemes, qui sont essen- 
tiellement des experts, a des procedures de vingt pages qui decrivent 
« comment ouvrir un Probleme », « comment le fermer », « comment 
escalader », etc. 

Il faut accepter une demarche modeste ou n’est ecrit que le strict 
necessaire exprime par les acteurs du processus eux-memes. Il est 
| done preferable de formaliser les plans de la fondation et de cons- 
| truire le chantier par etapes et en coherence avec la vitesse d’appro- 
I priation de Pensemble des acteurs du processus, e’est-a-dire au fur et 
| a mesure de leur maturite et de leur besoins exprimes au travers de 
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leurs experiences sur le processus. Autrement dit, ne pas aller plus 
vite que la musique ! 

N’oubliez pas que meme le management a l’origine du changement 
doit egalement s’approprier de nouvelles habitudes. 

Quant au manque de formalisation, il va projeter l’image d’un vide 
juridique pas du tout credibilisant pour un processus. Les acteurs 
n’auront pas envie d’adherer a un processus dont les bases leur 
semblent uniquement construites autour du principe de la bonne 
volonte de chacun, ou encore selon les diverses interpretations indi- 
viduelles qu’ils pourront avoir. 

Il faut etre convaincu d’une chose : meme si le trop-plein de proce- 
dures est clairement a eviter, le manque de procedures Test tout 
autant. 

Pour un deployment maitrise, il est utile de proceder a la mise en 
place d’un pilote et de bien choisir le perimetre de ce pilote. Il doit 
pouvoir servir d’exemple dans tous les sens du terme. Le pilote doit 
etre en mesure de mettre en evidence les plus et les moins de la 
demarche. 

Comment organiser la communication sur la mise en place 
d’un tel processus ? 

Dans la mise en place d’un processus, le plan de communication est 
une courroie de transmission essentielle pour promouvoir le change- 
ment qui s’opere dans l’organisation, non seulement pour les acteurs 
concernes au sein de la DSI, ou le management dans sa globalite, 
mais plus particulierement pour les acteurs du processus. 

La communication comprend des seminaries, des formations, des 
publications et lancements officiels d’evenements, ainsi que des 
reunions de bilan. La trame detaillee du plan de communication 
figure en Annexe 2. 

Vous trouverez ci-apres un exemple de lettre pour l’annonce de la 
mise en place des activites de la gestion des problemes. 

En plus d’une diffusion electronique et d’une publication sur l’intra- 
net de la direction informatique, ce type de lettre devrait faire l’objet 
d’un affichage dans les emplacements reserves a cet effet. 
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Cher Client, 


Un plus en matiere de soutien des services 
des debut mars 

Notre organisation s'efforce sans cesse d'ameliorer la qualite des 
services qui vous sont delivres. 

L'enquete de satisfaction Client realisee aupres de vous en janvier 
2008 nous a permis d'affiner notre vision et notre alignement vis-a- 
vis de vos besoins. A Tissue de cette enquete, vous etes nombreux a 
avoir attire notre attention sur : 

- vos souhaits d'amelioration de la disponibilite des services ; 

- vos attentes en informations par rapport aux plans d'actions enga- 
gees sur les incidents informatiques qui se repetent quotidiennement ; 

- vos besoins d'accompagnement quant au pilotage et au suivi des 
projets de fiabilisation des services informatiques. 

Cette annee, nous avons Tambition de mettre en place le processus 
de gestion des problemes afin de faire grandir mais aussi d'entrete- 
nir le patrimoine des bonnes pratiques existantes dans ces trois 
domaines en particulier. Par ce biais, nous avons la volonte de defi- 
nir des regies et des procedures pragmatiques qui vont nous permet- 
tre de faire reculer la non-qualite de service de fagon reactive mais 
aussi de fagon proactive. 

Ce chantier d'amelioration viendra renforcer la qualite des echan- 
ges entre nos structures via notre point central d'information : le 
Centre des Services metiers. 

Nous sommes actuellement, avec certains d'entre vous, en train de 
definir les « regies du jeu » qui vont permettre de demarrer de fagon 
optimale. La date de deployment du dispositif de gestion des pro- 
blemes est fixee a debut mars. Plus de details vous seront donnes sur 
les modalites de mise en oeuvre d'ici debut fevrier. 

C'est un changement qu'il nous faudra accompagner avec vous et 
|e suis convaincu qu'ensemble nous reussirons cette nouvelle etape 
de progres. Entre temps, si vous avez des questions, n'hesitez pas a 
me contacter au 06 XX XX XX XX. 

Tres cordialement, 

M. Paul Martin 

Responsable de la Gestion des Problemes 
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Quel peut bien etre le profil ideal d’un gestionnaire 

du processus de gestion des problemes ? 

Nous avons decline les roles et responsabilites du gestionnaire type 

sur le processus de gestion des problemes. Idealement, le profil 

adequat pour ce poste est une personne qui a : 

• le sens du pragmatisme, de la simplicity, et de l’objectif ; 

• une bonne connaissance et une bonne comprehension du contexte 
socioculturel de l’organisation dans laquelle il doit interagir ; 

• la reconnaissance de ses pairs et done la credibility pour accom- 
pagner le changement aupres des managers de chaque activity et 
de l’ensemble des acteurs operationnels ; 

• le pouvoir hierarchique transversal. Il doit avoir mandat pour faire 
executer les decisions directement dans les structures concernees 
sans etre dans l’obligation de faire valoir ce droit par l’interme- 
diaire du management de la structure concernee. Cela implique 
que les managers de structure sont pilotes en transversal par le 
gestionnaire ; 

• la capacite a prendre des decisions. Il a le sens aigu des responsa- 
bilites et fait des choix d’un commun accord avec les parties 
concernees ; 

• le sens de la rigueur et de l’organisation ; 

• un canal de communication directe vers les decideurs de la DSI. Il 
est essentiel que le gestionnaire puisse directement referer au 
haut decisionnaire de sa perception des difficultes observees et 
de la resistance au changement constatee. Ces informations sont 
des leviers pour l’ajustement de la strategic de developpement de 
l’organisation dans le cadre du processus ; 

• une capacite d’appropriation du contexte technique dans lequel 
evoluent les acteurs du processus ; 

• une excellente capacite d’endurance. La mise en place d’un 

processus est un travail qui s’opere petit a petit et done les resul- 
tats s’observent dans la duree. Il est important que le gestionnaire 
sache faire patienter les personnes pressees (bien souvent du cote g 
du management) par rapport au changement global ; 1 

• des qualites de bon communicant pour une gestion sereine et | 

maitrisee du changement organisationnel au sein de la DSL ° 
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II est conseille de confier au gestionnaire du processus de la gestion 
des problemes le management d’une equipe operationnelle (par 
exemple une equipe d’experts de la production informatique). Ce 
gestionnaire doit baigner dans le contexte des acteurs du processus 
qui, rappelons-le, sont essentiellement des experts. Pour etre credible 
vis-a-vis d’eux, il doit done connaitre leurs metiers, leurs contraintes, 
leurs difficultes. Cela lui permettra d’etendre sa credibilite vis-a-vis 
d’autres experts rattaches aux autres structures de la DSI (Etude, 
Hebergeur, Test, Reseau, Bureautique, etc.). Les pratiques auxquelles 
adhere sa propre equipe d’experts auront de bonnes chances de 
s’exporter plus facilement vers l’exterieur. . . 

L’expertise est un cercle dans lequel il faut d’abord entrer pour espe- 
rer faire valoir ses methodes. L’enjeu du gestionnaire du processus de 
gestion des problemes est de reussir a mettre en place cette proxi- 
mite avec les experts. Ce sont eux qui enclencheront la mise en 
marche du processus de gestion des problemes. 

Le gestionnaire doit veiller a 1’evolution et a Tamelioration continue 
de son processus. 

ITIL evoque l’importance du processus de gestion 
des problemes par rapport a l’entreprise, mais qui en est 
le porte-parole au quotidien ? 

Effectivement, de par l’objectif du processus de gestion des proble- 
mes, il est important de savoir identifier ce qui est le plus important a 
traiter pour l’entreprise. Dans la realite, et ce pour de nombreuses 
organisations, les vrais acteurs decisionnaires sur ces questions ne 
sont pas accessibles a des niveaux operationnels. Au quotidien, il 
appartient aux acteurs operationnels de se former a 1’evaluation des 
impacts occasionnes par les problemes et d’actionner les leviers 
d’escalades adequats pour valider les decisions structurantes. 

La certitude d’une adequation, entre la decision des operationnels et 
la vision des decisionnaires qui ont Tangle de lecture le plus fin sur la 
question, n’est pas garantie. 

Dans ce cas, et pour s’assurer de prendre les decisions les plus 
j coherentes possibles, il est conseille de faire intervenir le gestion- 
J- naire des niveaux de services afin qu’il valide les priorites definies 
§• pour le traitement des problemes. Pilotant quotidiennement les 
| niveaux de services et connaissant les enjeux au travers de la 
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maTtrise de son contrat de service, le gestionnaire de services 
detient une vision essentielle pour garantir la coherence des affaires 
de l’entreprise. 

Est-il possible de mettre en place la gestion des problemes sans 
CMDB (Configuration Management Database) ? 

II sera difficile voire chaotique de mettre en place la gestion des 
problemes sans avoir une base Incidents. Une base de gestion des 
elements de configurations n’est par contre pas indispensable. En 
effet, le processus de gestion des problemes doit imperativement 
disposer de la matiere premiere la plus pertinente possible sur la 
gestion des incidents enregistree par le Centre de services. Ce dernier 
va pouvoir s’appuyer sur la CMDB (base de donnees pour la gestion 
des elements de configuration du systeme d’information) pour identi- 
fier les services affectes par l’incident et les elements de configura- 
tions qui contribuent a la delivrance du service. Dans le cas contraire, 
la matiere premiere peut etre acquise par des moyens de contourne- 
ment comme : 

• le catalogue de services fourni par le gestionnaire de service ; 

• la capitalisation des impacts sur les incidents deja enregistres ; 

• la base de connaissances. 

II faut done retenir que le processus de gestion des problemes peut 
se passer d’une CMDB a condition que la gestion des incidents inves- 
tisse un peu plus de temps pour assurer la pertinence et la mainte- 
nance des donnees de la base des Incidents en palliant l’absence de 
la CMDB. 

Quel est le moyen le plus simple pour le management de verifier 

que la gestion des problemes agit ou a prevu d’agir 

sur tous les sujets qui vont ameliorer la qualite de service ? 

Pour s’assurer d’un alignement efficace entre les actions menees au 
travers du processus de gestion des problemes et l’amelioration 
attendue sur la qualite de service, le management devrait disposer 
d’un tableau de bord des services critiques de l’entreprise (une 
production mensuelle peut etre suffisante). Dans ce tableau de bord, g 
l’idee est d’avoir en visibility : 1 

• un indicateur agrege des niveaux de services sur les services | 

critiques ; g 
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• un volet conformation detaille et concentre sur les indicateurs de 
niveau de services non respectes sur le mois, pour ces services 
critiques ; 

• une explication sur le non-respect du SLA sur ces services criti- 
ques, ainsi que le plan d’actions associe. 

Ce type de rapport permet de communiquer de fayon concrete sur 
l’amelioration de la qualite des services importants pour l’entreprise 
et ce, surtout par l’apport de la gestion des problemes. 

La premiere etape consiste a definir les services critiques de 
l’entreprise : ceux qui vont influencer la confiance ou la defiance du 
client final vis-a-vis du service offert par l’entreprise. Par exemple, 
pour un operateur de telecommunications, un service critique offert 
au client final pourrait etre : « Service clientele ouvert de 08h00 a 
22h00 du lundi au dimanche, jours feries inclus, sans interruption ». 
Ensuite, on cerne et on fixe un objectif ambitieux d’amelioration de 
ces services critiques. Pour reprendre l’exemple precedent, l’objectif 
pourrait etre : « 95 % de taux de prise en charge des appels client 
finaux sur la plage d’ouverture du service clientele ». L’amelioration 
de la qualite des sous-services contributeurs est evidemment obliga- 
toire. Cela va introduire les questions suivantes : 

• La qualite des sous-services contributeurs a l’atteinte de la qualite 
du service global est-elle suffisante ? 

• Les composants informatiques qui contribuent a la qualite de ce 
service sont-ils fiables ? 

Dans le tableau de bord des services critiques, le volet d’information 
sur les indicateurs de niveaux de services non respectes doit inclure 
une explication comprenant a minima : 

• le probleme (et son n° de reference) ; 

• la cause ; 

• le plan d’actions avec : 

- une solution provisoire ; 

„ - une solution definitive. 

| Si votre gestion des problemes se preoccupe reellement des proble- 
I mes qui abaissent la qualite de service, elle se soucie a plus forte 
| raison de ceux qui abaissent la qualite des services critiques. 
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Le management devra done verifier dans le tableau de bord des 
services critiques que le traitement d’un probleme est mentionne 
pour les services critiques dont l’atteinte du SLA (Service Level Agree- 
ment) ou du SLR (Service Level Request) ne sont pas respectes. 

Quel resultat escompter la premiere annee de mise en place 
du processus ? 

Le management se pose cette question lors de la mise en place du 
processus de gestion des problemes (et egalement d’autres proces- 
sus d’ailleurs). Meme si les gains sont legion, comme nous les 
avons cites dans un precedent chapitre, il faut neanmoins garder la 
tete froide. 

Le premier defi qui doit mobiliser tous les acteurs de la DSI est de 
reussir et former cette chaine d’activite qui va souder le processus de 
bout en bout, et le faire exister de fagon transversale dans l’organisa- 
tion. En effet, l’appat du gain risque de vous eloigner du premier 
objectif qu’il vous faudra atteindre dans le cadre de la mise en oeuvre 
du processus : l’accompagnement du changement. Si la communica- 
tion est axee sur les gains a obtenir, les acteurs risquent d’agir comme 
des mercenaires pour rechercher ces benefices. 

Vous gagnerez peut-etre des pepites dans un premier temps, mais il 
est clair que vous ne pourrez pas perenniser un tel systeme qui 
s’epuisera de lui-meme dans la duree a cause de son inefficacite (les 
pepites seront plus difficiles a trouver au fil du temps). 

La mise en place du processus de gestion des problemes est avant 
tout un pari d’organisation et d’apprentissage de methode. Si le 
processus est bien assis, e’est-a-dire qu’il fait corps avec l’organisa- 
tion dans son execution sur le terrain des operationnels, alors les 
gains viendront doucement au demarrage, et crescendo au fur et a 
mesure de la maturite. 


© 


Cette evolution fait partie integrante d’un processus d’accompagne- 
ment du changement que nous vous proposons de representer dans 
ce schema. 
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Figure 9.4 : L’accompagnement du changement 

Ces 7 etapes sont necessaires a tous les supports d’expertise de la 
DSI. Ne soyez done pas impatient sur les gains. Soyez perseverant 
sur l’atteinte de la mise en place du changement dans l’organisation. 
Retenez egalement qu’une bonne conduite du changement ne peut 
etre faite sur le ton du « quoi qu’il arrive, nous ferons ceci, nous irons 
la, nous mettrons telle chose en place, nous gagnerons cela, etc. ». 
Seules l’analyse et la comprehension des circonstances peuvent et 
doivent permettre de determiner la fagon dont le changement doit 
s’operer. 


Role a prevoir pour accompagner le changement 

Cette partie a pour objectif de presenter les roles et missions 
de Vequipe et plus globalement du dispositif de conduite du 
changement pour la mise en place du processus de gestion 
des problemes. 
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Nous tacherons d’apporter des informations sur les missions 
prises en charge par les acteurs de Vencadrement et du 
deployment du processus. 

Nous apporterons des reponses aux questions suivantes : 

Que fait le sponsor ? Le directeur de projet ? Le gestionnaire ? 
Le proprietaire ? Le comite de direction ? Etc. 


Pour conduire le plan de transformation de la DSI avec l’implementa- 
tion ou l’optimisation de la gestion des problemes, il va etre neces- 
saire de definir de fagon claire les roles de chacun pour le pilotage et 
l’accompagnement de ce changement. Un modele de repartition des 
roles au sein de l’equipe vous est propose dans le tableau suivant. 
Les responsabilites associees sont detaillees en Annexe 3- 


Role 

Mission 

Sponsor 

Donne la direction sur le projet de transformation. A le pouvoir de 
decision sur la structuration de I’organisation et des metiers. 

Comite de direction 

Le comite de direction intervient en tant que comite executif dirige 
par le sponsor. 

Comite Projet 

Le comite Projet est le maTtre d’oeuvre du projet. II est dirige par le 
chef de projet, et est responsable de tracer la ligne directrice 
definie par le comite de direction. 

Directeur de projet 

Le directeur de projet est le responsable des jalons sur I’ensemble 
du projet de transformation pour le compte du sponsor. II est le 
garant de la bonne tenue du comite Projet. 

Conseil : rattacher physiquement et operationnellement le 
directeur de projet au sein meme du service vise en tout premier 
lieu par le changement que vous conduisez. Cela permet une 
proximite entre le « monde projet » et le « monde reel ». 

Proprietaire 
processus de gestion 
des problemes 

Le proprietaire du processus est le garant de la satisfaction des 
clients sur son processus et a ce titre il est responsable des 
resultats du processus. II est rattache fonctionnellement au 
sponsor. 

Gestionnaire 
processus de gestion 
des problemes 

Le gestionnaire de processus est le garant de la mise en oeuvre et 
de la performance du processus. II depend fonctionnellement du 
proprietaire de processus. 

1 est responsable par delegation de la mise en oeuvre des 
ameliorations arbitrees par le proprietaire dans son domaine. 
Assurez-vous de lui donner les moyens de cette gestion. 

Operateurs du 
processus de gestion 
des problemes 
ou assistant du 
processus de gestion 
des problemes 

L’operateur du processus est responsable d’activites definies dans 
le cadre du processus. Ces activites font i'objet d’un rapport au 
gestionnaire de processus. 
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Demarche de mise en ceuvre 

Ce chapitre a pour objectif de presenter la demarche de mise 
en ceuvre du changement lors de la mise en place du 
processus. 

Nous tacherons de preciser les etapes cles a respecter pour 
detenir la vision la plus pertinente possible afin de conduire 
efficacement la mise en place des ameliorations de proces- 
sus. 

Nous apporterons des reponses aux questions suivantes : 

Quelles sont les etapes d ’organisation d’un projet de mise en 
place de processus (ou meme de son amelioration) ? 

Comment les mettre en oeuvre concretement ? 

La demarche d’organisation du projet de deployment ou d’ameliora- 
tion du processus est pilotee par le gestionnaire du processus et doit 
suivre un cheminement reposant sur une logique de pensee organi- 
see autour de 6 phases. 


Amelioration 



Figure 9.5 : Organisation du deployment du processus 
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Observer 

Etape 1 : Analyser I’existant 

Comprendre 

Etape 2 : Critiquer I’existant 

Analyser 

Etape 3 : Realiser le diagnostic 

Choisir 

Etape 4 : Elaborer et choisir des solutions 

Agir 

Etape 5 : Mettre en oeuvre 

Controler 

Etape 6 : Suivre et ajuster 


Etape 1 : Analyser l’existant 

C’est l’action qui va consister a decrire de fagon objective et concrete 
le fonctionnement present du ou des processus de Torganisation. Le 
but est d’etre en mesure de realiser une photographie de l’organisa- 
tion et de son fonctionnement a un instant t. 

Cette etape est done le point de demarrage par lequel viendra 
l’impulsion du changement. Elle consiste a recueillir et a consolider 
Tensemble des informations qui vont permettre d’identifier les caren- 
ces et les difficultes de Torganisation. Elle vise egalement a favoriser 
la prise de conscience par tous, des insuffisances ou des insatisfac- 
tions en lien avec la situation actuelle. C’est une cle pour donner aux 
acteurs l’envie de s’ameliorer. 

C’est une phase d’observation avant tout. II est done important de 
rester neutre. 

Etape 2 : Critiquer l’existant 

C’est Taction qui va consister a faire apparaitre les points forts et les 
points faibles de fonctionnement sur le ou les processus etudies. 
Cette etape va done permettre de : 

• Faire emerger par les acteurs, les points forts et les dysfonctionne- 
ments du processus etudie. 

• Proceder, dans le cadre d’une demarche individuelle du gestion- 
naire de processus, a une analyse critique de Texistant. 

Etape 3 : Realiser le diagnostic 

C’est Taction qui va consister a hierarchiser l’importance de chaque 
cause donnant lieu a un dysfonctionnement ou a une difficulty dans J 
le processus afin d’y apporter les solutions adequates et en cohe- J- 
rence avec Tenvironnement socioculturel, le style de management, | 
ou encore la structure concernee. Cette etape va done permettre de : ® 
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• Qualifier l’importance de chacun des dysfonctionnements identi- 
fies sur le processus. 

• Mesurer l’ecart entre les objectifs de l’organisation, de l’entreprise 
et la situation actuelle. 

Etape 4 : Elaborer et choisir les solutions 

C’est Taction qui consiste a recenser Tensemble des solutions suscepti- 
bles d’apporter une correction a la situation des dysfonctionnements 
identifies comme etant les plus penalisants pour le processus. Ce 
recensement devra egalement permettre de choisir la meilleure solu- 
tion a mettre en oeuvre. En finalite, cette etape va done permettre de : 

• Lister les solutions et/ou axes d’ameliorations permettant de corri- 
ger les dysfonctionnements du processus. 

• Selectionner les solutions qui vont correspondre le mieux aux 
besoins a satisfaire et aux contraintes a respecter. 

Voici une matrice devaluation pour les rubriques suivantes : 


Couts de mise en oeuvre 


51 a 100 k€ inclus 


0 a 50 k€ inclus 


1 a 3 mois inclus 


3 a 6 mois inclus 


Gains : QoS / Satcli (alignement avec les enjeux) 


Chiffrage gain QoS 
et/ou Satcli 

7 

8 

9 

Gain QoS ou Satcli ou 
Reponse au moins a un enjeu (*) 

4 

5 

6 

Pas devaluation 

1 

2 

3 


Pas 

devaluation 

< 1 ETP an 

> 1 ETP an 


Legende : 

ETP : Equivalent Temps Plein - 1 ETPjour : 530 €- 1 ETP an : 104 410 € 
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Le gain doit imperativement etre en alignement avec l’enjeu de 
l’entreprise. Quelques exemples d’enjeux globaux pour lesquels le 
processus de gestion des problemes est contributeur : 

• Ameliorer la qualite de service de notre interface avec les metiers. 

• Augmenter la qualite de service de nos produits a un cout opti- 
mise et de fagon perenne. 

• Rationaliser les activites tout en specialisant le contact client. 

• Diminuer les pertes de CA. 

• Augmenter la satisfaction de nos clients internes vis-a-vis des 
ressources informationnelles. 

• Capitaliser notre connaissance. 

• Eliminer les risques de crise interne ou de crise d’entreprise. 

• Industrialiser le systeme d’information tout en le rendant agile 
face aux exigences des clients. 

Une fois evalue, le classement des ameliorations peut etre represente 
a l’aide de la structure de decision du schema suivant : 



Figure 9.6 : Classement des ameliorations 
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Etape 5 : Mettre en oeuvre 

C’est Faction qui va consister a organiser et piloter la mise en oeuvre 
des solutions/axes d’ameliorations decides pour resoudre les 
dysfonctionnements et/ou combler les manques du processus etudie. 
En finalite, cette etape va done permettre de : 

• Mettre au point un plan d’actions detaille de mise en oeuvre de la 
solution et/ou axe d’amelioration validee. 

• Tester la solution/axe d’amelioration validee dans le cadre d’un 
pilote. 

• Deployer la solution/axe d’amelioration. 

Etape 6 : Suivre et ajuster 

C’est Faction qui va consister a verifier et s’assurer de la bonne 
appropriation de la solution et/ou de l’axe d’amelioration mise en 
place vis-a-vis de l’ensemble des acteurs concernes. Cette action va 
egalement permettre de suivre les realisations au quotidien et d’adap- 
ter les solutions et/ou axes d’amelioration en fonction des evolutions. 
En finalite, cette etape va done permettre de : 

• Controler la mise en oeuvre de la solution et/ou de l’axe d’amelio- 
ration. 

• Mesurer les resultats obtenus. 

• Apporter des corrections ou des modifications en fonction des 
evolutions / amenagements necessaires. 

Le detail des actions a entreprendre figure en Annexe 4. 


Pensez systematiquement a mettre a jour la cartographie « boTte blanche » du 
processus, la description des roles et responsabilites inherents au processus 
concerne, ainsi que pour les processus affectes. 


Quelques pieges a eviter 

Cette partie a pour objectif de faire etat des difficultes ris- 
quant de compromettre la mise en oeuvre du processus de 
gestion des problemes. 


190 Ameliorer la qualite des services 


Nous traiterons de quelques interpretations pouvant preter a 
confusion dans le cadre de la comprehension du processus 
de gestion des problemes. 

Nous apporterons des reponses aux questions suivantes : 

Quels sont les objectifs que la gestion des problemes ne pour- 
suit pas ? Pourquoi ? 

Quelles sont les erreurs a ne pas commettre ? 

De nombreuses DSI sont convaincues de deja tout comprendre et 
tout faire concernant les objectifs enonces plus haut. Mais alors 
comment expliquer que la qualite de service ne s’ameliore pas de 
fagon continue ? 

II est frequent qu’un certain nombre d’ambigu'ites subsiste dans les 
esprits, meme de ceux qui ont la charge du pilotage d’un processus 
comme celui de la gestion des problemes au sein des DSI. Lorsqu’on 
s’emmele les pinceaux dans la logique de ce processus ou que les 
explications que Ton utilise pour le decrire sont equivoques, il devient 
difficile d’en tirer toute la performance que Ton en attend. N’oubliez 
pas que plus de la moitie du chemin vers la qualite de service tient 
dans l’effort de pedagogie et de soutien que l’organisation a la capacite 
a mettre en oeuvre pour accompagner les methodes. Il est done utile 
de bien connaitre et de bien comprendre ce qui distingue la gestion 
des problemes de certains autres processus. Pour ce faire, il est neces- 
saire de reconnaitre et de savoir eviter quelques pieges : 


1 er piege 

Le processus gestion des problemes n’a pas pour objectif de resoudre les 
incidents dans les plus brefs delais. II s’agit de I’objectif de la gestion des 
incidents. Cela pourra paraitre evident pour certains, mais nombreuses sont 
les organisations DSI dans lesquelles le temps des experts est a 95 % 
cannibalise par la resolution des incidents. 


Dans ce cas, les experts n’ont pas le temps de se consacrer a la recher- 
che des causes sous-jacentes et a l’etude de solution aux problemes j 
enregistres. Cette situation entrame l’organisation a etre entierement J> 
dependante d’un mode de gestion reactive par les meilleurs, ce qui | 
creuse le deficit de capitalisation vers les niveaux de support inferieur ° 
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et empeche l’organisation d’etre proactive et done de mettre en oeuvre 
les actions anticipees pour maintenir la qualite de service. 


2 e piege 

Le processus gestion des problemes n’a pas pour objectif de resoudre tous les 
problemes. Contrairement a la gestion des incidents qui effectivement vise la 
resolution de tous les incidents jusqu’au dernier, le processus de gestion des 
problemes s’attache a la resolution des problemes qui en valent la peine. 
L’objectif etant essentiellement de gagner en qualite de service ou en 
economie des couts sur les efforts de soutien aux services, la gestion des 
problemes investit du temps dans ce qui rapporte le plus. 


Les experts n’ont alors plus le temps d’etre reactifs et d’apporter leur 
support a la gestion des incidents. Les dossiers d’incidents qui neces- 
sitent leur conseil ou leur expertise ont du mal a trouver echo aupres 
d’eux. En parallele a cela, les problemes traites par les experts 
n’apportent pas les gains de qualite de service tant esperes. Si les 
problemes sont tous traites (a tort), ceux qui prennent peu de temps 
d’investigation sont privilegies par rapport a d’autres plus importants 
pour l’entreprise. 


3 e piege 

Le processus gestion des problemes n’a pas pour objectif de diminuer le 
nombre d’incidents. L’amalgame est frequent. La diminution du nombre 
d’incidents est un gain issu de I’implementation du processus. Nous pourrions 
meme dire que e'est une consequence, mais il ne s’agit aucunement de son 
objectif premier. Si vous aviez dans I’idee de penser que la gestion des 
problemes aurait pour objectif de diminuer le nombre d’incidents, et que vous 
aviez imagine donne la priorite a la resolution de vos problemes en mettant sur 
le haut du panier les problemes qui rassemblent le plus grand nombre 
d’occurrence d’incidents, alors vous vous etes trompes ! 


Les experts risqueraient de comprendre que vous attendez d’eux 
qu’ils traitent les problemes auxquels se rattache le plus grand 
nombre d’incidents. Seulement les problemes auxquels se rattache 
un seul incident peuvent etre autant prioritaires que ceux auxquels 
| se rattachent une multitude d’incidents du fait de leur repercussion 
J- plus importante sur l’entreprise. Du coup, vous n’aurez pas l’assu- 
I ranee que le travail effectue par vos experts va bien aboutir au gain 
| attendu en qualite de service. 
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4 e piege 

Le processus gestion des problemes n’a pas pour objectif de planifier les 
changements visant a corriger les erreurs dans le SI. Chacun son role. II s’agit 
la du travail de votre gestion des changements. Le processus de gestion des 
problemes ne doit pas « reinventer la poudre » lorsqu’il a besoin de faire 
realiser ou de mettre en production un changement. II est bien sur vivement 
conseille d’accoler le processus de gestion des problemes au processus de 
gestion des changements existant dans votre organisation. 


Les changements planifies en local par les experts risquent d’entrer 
en conflit avec ceux planifies par votre gestion des changements. De 
plus, ces changements ont de fortes chances de ne pas suivre un 
modele de tragabilite equivalent a celui prevu dans le cadre de votre 
processus de gestion des changements. Une mauvaise gestion des 
conflits entre les changements est susceptible de generer des inci- 
dents et done d’abaisser la qualite de service. Le manque de tragabi- 
lite et/ou l’heterogeneite du mode operatoire de tragabilite des 
changements risquent fortement de rallonger les delais de retablisse- 
ment du service. 


5 e piege 

La recherche des causes sous-jacentes de rupture ou degradation de service 
ne fait pas partie des activites de la gestion des incidents. Rappelez-vous que 
la gestion des incidents traite les consequences (les effets) et non les causes. 
II faut bien distinguer une difference entre : 

- la cause initiale fournie par la gestion des incidents ; 

- la cause sous-jacente fournie par la gestion des problemes. 


Qu’est-ce qui distingue alors la cause initiale de la cause sous- 
jacente ? La figure 9-7 differencie les deux causes. 

La cause initiale est une cause apparente. Elle peut done etre decelee 
plus aisement durant les investigations engagees par la gestion des 
incidents pour retablir le service. 

La cause sous-jacente est l’arbre qui cache la foret. Elle va nous 
permettre de reveler au grand jour (apres examen approfondi) la 
raison qui explique pourquoi : 

• Des symptomes qui paraissent a priori sans rapports entre eux J 

peuvent en fait etre lies. J- 

• Plusieurs causes apparentes provenaient des effets d’une meme | 

cause cachee. ° 
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Cause initiale 


Cause apparente ► 

L'hypothese serieuse 
(repose sur des faits precis) 


Cause sous-jacente j ►; Cause cachee : ► Le mobile 


Figure 9.7 : Difference entre cause initiale et cause sous-jacente 


La cause apparente est un point d’ancrage fondamental pour la 
gestion des problemes, mais il est important de bien borner la 
gestion des incidents sur ce terrain, car son objectif n’est pas de trou- 
ver le mobile du crime. Ce travail est issu de l’enquete instruite par le 
processus de gestion des problemes. 

La gestion des incidents qui part en croisade a la recherche de la 
cause sous-jacente perd en efficacite sur le delai de resolution de ces 
incidents (qu’il faut tous traiter dans les delais convenus). Pourquoi ? 
Parce que la recherche de la cause sous-jacente demande d’y investir 
du temps. Lorsque la gestion des incidents ne sait plus traiter ces inci- 
dents dans les delais, ce phenomene se paye comptant par un abais- 
sement de la qualite de service (et bien sur au passage de la 
satisfaction client). 


6 e piege 

Le processus gestion des problemes n’a pas pour activite de recevoir en direct 
les problemes que pourraient identifier les utilisateurs ou de communiquer aux 
utilisateurs sur I’avancement des problemes. 

Par exemple, un utilisateur constate une defaillance sur son ordinateur : la 
messagerie ne fonctionne plus. Ce n’est pas la premiere fois que cela arrive, et 
regulierement I’utilisateur fait appel au Centre de services qui fait des 
operations de maintenance a distance afin de pouvoir retrouver I’usage de sa 
| messagerie. Malgre le caractere recurrent de cette panne, I’utilisateur devra 
| continuer de declarer ce dysfonctionnement au Centre de services. 

8, Cette panne ne devra en aucun cas etre declaree au gestionnaire des 
| problemes. 

© 
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En effet, le Centre de services perd son interet premier qui est celui 
d’etre le point de contact privilegie de vos utilisateurs. Vous leur avez 
repete que, pour bien les satisfaire, il etait important qu’ils appellent 
le Centre de services lorsqu’ils ont une plainte, ou lorsqu’ils consta- 
tent un incident sur leurs outils de travail. Ils s’y etaient habitues. 
Seulement, depuis que vous avez permis aux utilisateurs de declarer 
ou demander l’ouverture d’un Probleme en se mettant directement 
en relation avec la cellule de la gestion des problemes, cela a eu pour 
consequence de deporter pour moitie le nombre d’appels du Centre 
de services vers cette cellule. Elle ne sait plus comment faire pour 
repondre aux sollicitations des utilisateurs. 

Il est clair que le temps passe a ecouter ces utilisateurs et expliquer 
aux experts qu’ils ont decouvert un probleme ne permet pas d’inves- 
tir a proprement parler sur la recherche des solutions aux problemes 
qui vont concourir a l’amelioration de la qualite de service. 

De plus, le Centre de services est decredibilise ; les appels ne sont 
plus tous aussi bien traces, done la gestion des problemes a du mal a 
etre alimentee par une correlation pertinente sur la base de l’ensem- 
ble des dysfonctionnements rencontres sur le systeme d’information. 
De toute evidence, la qualite de service ne s’obtiendra pas de cette 
fagon. Vous trouverez en Annexe 5 une liste non exhaustive mais qui 
represente les ecueils les plus frequemment rencontres, lorsqu’on 
souhaite mettre en place une gestion des problemes. 


© 



Chapitre 9 

Evaluer la maturite 


Le modele de maturite 

Cette partie a pour objectif de presenter les differents 
niveaux de maturite ITIL qui s’appliquent au processus. 

Nous aborderons egalement dans ce chapitre une technique 
permettant d’evaluer la maturite du processus de gestion des 
problemes et de gestion des incidents (les deux etant lies, il 
est interessant de suivre leur evolution defagon conjointe). 

Nous apporterons des reponses aux questions suivantes : 
Combien de niveaux de maturite existe-t-il ? 

Que signifient-ils ? 

Comment jauger la maturite du processus de gestion des 
problemes ? Avec quels outils ? 

Pour la plupart des entreprises, la difficult^ d’implementation ou 
d’amelioration du processus de gestion des problemes tient finale- 
ment au fait que le processus est partiellement existant et que les 
manques sont difficiles a qualifier. Par ou commencer ? 

Plusieurs modeles d’echelle de maturite permettent de se situer pour 
determiner les marches restant a gravir et denicher les ameliorations 
pertinentes a engager et les planifier. 
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Le modele de maturite selon ITIL 

Les paliers de maturite situent la capacite d’une organisation informa- 
tique a aligner ses services sur la strategic de l’entreprise. Plus l’orga- 
nisation est mature, plus elle cree de la valeur pour l’entreprise. 
Chaque palier de maturite correspond a une coherence entre la 
vision partagee, les directives du management, les processus mis en 
place, les competences et l’implication des acteurs, et l’outillage 
supportant les processus. Les stades de maturite identifies dans le 
referentiel ITIL sont : 

• le niveau technologique ; 

• le niveau produit ou service ; 

• le niveau oriente client ; 

• le niveau oriente affaires ; 

• le niveau chame de valeur. 

La courbe de maturite est le concept visant a evaluer le niveau de 
maturite d’une organisation informatique. Cette evaluation est repre- 
sentee par une courbe, permettant un benchmarking (analyse 
comparative) avec d’autres organisations. Ce concept a ete invente 
par le Gartner Group en 2003. 

Le niveau de maturite s’evalue sur la coherence entre les composan- 
tes essentielles d’une politique de services : 

• la vision (partagee) ; 

• le management ; 

• les processus ; 

• les hommes (competences et implications) ; 

• les outils supportant les processus ; 

• la culture de l’organisation. 

L’evaluation se base sur une echelle de niveaux de maturite 
employee dans d’autres referentiels (CMMi) : 

• niveau initial ; 

• niveau reproductible 

• niveau defini ; 

• niveau gere ; 

• niveau optimise. 
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Figure 10.1 : Echelle de niveau de maturite du processus 


II ne s’agit pas d’une demarche a apprendre par coeur, mais a aborder 
de la fagon la plus transparente qui soit. Elle vous permettra de 
savoir ou vous en etes dans la maturite de votre processus de gestion 
des problemes et vous aiguillera sur les chantiers d’ameliorations a 
engager. 

Detaillons les differents niveaux. 

Niveau 1 Initial : ce premier niveau de maturite est la phase d’initia- 
tion du processus. Vous etes dans cette phase initiate si votre 
organisation : 

• Reconnait la necessite du processus de gestion des problemes 
tout en s’avouant qu’il est inexistant, realise de fagon chaotique, 
ou au coup par coup a la demande expresse du management. 

• Reconnait un manque de gestion evident du processus sans avoir 
fait le pas de nommer un gestionnaire attitre pour prendre en 
charge sa gestion. 

• Reconnait qu’aucun moyen a la hauteur de l’accompagnement du 
changement necessaire pour l’implementation de ce processus n’a 
ete mis en oeuvre. 

| Niveau 2 Repetable : le second niveau de maturite est la phase des 

'S premiers pas. Vous etes dans cette phase si votre organisation : 

| • Plebiscite l’utilite du processus de gestion des problemes. 
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• A mis en place des moyens permettant d’allouer des ressources 
pour sa gestion. 

• Constate malgre tout que les activites du processus sont encore 
pilotees de fagon irreguliere, partielles ou empirique, sans certi- 
tude de son aboutissement, meme si des resultats sont visibles a 
Tissue de ces activites. 

• Ne peut apporter la preuve que le processus remplit sa mission 
(manque d’indicateurs de performance). 


Niveau 3 Defini : le troisieme niveau de maturite est la phase de la 

formalisation. Vous etes dans cette phase, si votre organisation : 

• A pris conscience de Timportance du processus de gestion des 
problemes en interne. 

• A documents le processus de gestion des problemes (cartogra- 
phic, definition des roles et responsabilites, audit des outils). 

• A nomme un gestionnaire du processus qui definit les objectifs et 
pilote des ressources qui lui sont allouees. 

• A identifie un proprietaire qui definit les lignes directrices sur la 
definition du processus et son efficacite. 

• N’a pas reussi a trouver un consensus formel entre chaque partie 
prenante pour la mise en application des roles decrits dans la 
documentation du processus. 


Niveau 4 Gere : le quatrieme niveau de maturite est la phase d’accep- 

tation et de rodage. Vous etes dans cette phase si votre organisation : 

• A documents le processus gestion des problemes ainsi que 
l’ensemble de ces interfaces internes/externes. 

• A integre toutes les activites du processus defini, dans ses prati- 
ques recurrentes. 

• Legitime Timportance du processus et a reussi a le faire reconn ai- 
tre aupres de Tensemble de la DSI. 

• Mise sur une orientation du processus exclusivement tournee vers J- 

les services, en definissant des objectifs de gestion de problemes | 
en alignement avec les exigences de vos clients. ° 
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Publie des rapports examines lors de comite de pilotage sur les 
actions prioritaires institutes par la gestion des problemes. 

Peut justifier d’une gestion du processus par l’intermediaire d’indi- 
cateurs de performance du processus et d’une capacite a anticiper 
les prochaines ameliorations necessaires au processus. 


Niveau 5 Optimise : le dernier niveau de maturite est la phase dans 

laquelle on observe une maitrise de l’efficacite et de l’efficience du 

processus. Vous etes dans cette phase si votre organisation : 

• A entierement integre l’existence du processus au patrimoine 
organisationnel de l’entreprise. 

• Pilote des objectifs directement alignes aux enjeux de l’entreprise, 
en s’assurant d’un retour sur investissement dans son usage quoti- 
dien du processus. 

• A optimise son processus dont la performance presente des resul- 
tats qui atteignent les objectifs fixes, et repondent a ceux de 
l’entreprise. 

• A mis en place un pilotage de l’amelioration continue du proces- 
sus afin de maintenir l’ensemble des activites du processus a un 
niveau optimal. 

L’identification et la locaUsation des faiblesses du processus 

La force du processus est conditionnee par le respect de trois 

principes : 

• La definition des objectifs portes par le processus doit etre en 
coherence avec un alignement client. 

• Le management de l’organisation doit etre en support de l’interre- 
lation de chaque processus de l’organisation afin de rendre effi- 
cace et coherent le pilotage operationnel de cette organisation. 

• La definition des procedures doit decrire des operations a suivre 
pour enrichir les pratiques operationnelles du terrain qui elles- 
memes doivent s’integrer dans l’equilibre de l’interrelation avec 

« d’autres processus voisins. 

| La verification de ces trois principes doit permettre de mettre en 
I evidence les points faibles du processus et donne un point de depart 
| pour l’identification des axes a trouver pour l’amelioration du processus. 
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Figure 10.2 : Principes de verification et audit du processus 

Le questionnaire ci-dessous doit permettre d’evaluer ou vous en etes 
sur chacune de ces interrelations continues. 

Le pourcentage de reponse positive a chacune des questions permet 
d’evaluer l’adequation entre le fonctionnement existant et celui qui 
devrait etre au sens du processus evalue. 

L’objectif etant d’approcher les 100 % de chacun des elements, 
l’objectif va consister a identifier en priorite les axes d’ameliorations 
sur l’element ayant le taux d’adequation le plus faible. 

Par ricochet, les ameliorations mises en oeuvre sur ces points faibles 
vont participer a optimiser l’interrelation des elements qui leur sont 
directement connectes : 

• definition des objectifs vs alignement client pour un meilleur 
controle du resultat ; 

• definition des procedures vs pratique operationnelle vs interrela- 
tion processus pour un meilleur controle des operations ; 

• management vs interrelation processus vs pilotage operationnel 

pour un meilleur controle de l’organisation. g 

Vous trouverez ci-dessous une check-list de questions permettant J- 
d’evaluer les points de faiblesses du processus de gestion des proble- | 
mes au sein de votre organisation. ° 
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Alignement client 

1 

Les objectifs et les gains de la gestion des problemes ont-ils fait I’objet d’une 
information a I’ensemble des acteurs de la Direction ? 

2 

Toutes les structures de la DSI se sont-elles engagees a ameliorer la qualite de 
service ou a reduire la duree des interruptions de services ou d’activites en support 
au service rendu ? 

3 

Existe-t-il une verification sur I’alignement des activites de la gestion des problemes 
vis-a-vis des besoins et exigences des utilisateurs ? 

4 

L'enquete de satisfaction client prevoit-elle de sonder les utilisateurs et les clients 
sur I’efficacite de la gestion des problemes ? 

5 

La perception de la qualite de service par les utilisateurs fait-elle I’objet d’un plan 
d’actions decline en objectifs aupres de la gestion des problemes ? 


Definition des objectifs 

1 

L’objectif d’amelioration de la qualite de service est-il mesure ? 

2 

L’objectif de reduction des couts prohibitifs de support est-il mesure ? 

3 

L'objectif de reduction des periodes d'interruption de services est-il mesure ? 

4 

Les applications au cceur du metier de I’entreprise font-elles I’objet d’une gestion 
proactive des problemes avec l’objectif d'atteindre le SLR ? 

5 

La diminution des escalades vers les supports de 2 e et 3 e niveau est-elle 
mesuree ? 



Pratique operationnelle 

1 

Existe-t-il des activites qui s’assimilent a : 

• la detection d'incidents recurrents ; 

• I’analyse approfondie des incidents a fort impact sur I’entreprise ; 

• la surveillance et le controle de toutes les modifications apportees sur les 

environnements de production ; 

• la recherche de I’origine des causes de non qualite de service ; 

• I’etude et la mise en place de correctif dans l’objectif d’attenuer ou d’annuler 

definitivement ce type d’impacts ? 

2 

Les risques ou les causes potentielles de non-qualite de service sont-ils recherches 
de fagon reguliere, avant qu'une alteration ou une rupture du service ne soit 
declaree par le Centre de services ? 

3 

Les acteurs de la gestion des problemes ont-ils a disposition toutes les informations 
sur les incidents (classification, description, services touches, historiques des 
actions de diagnostics et actions entreprises pour le retablissement de services) ? 
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4 

Existe-t-il un mecanisme permettant d’effectuer le suivi de la resolution des 
problemes ? 

5 

Les elements permettant la description du probleme sont-ils systematiquement 
renseignes dans le cadre de I’enregistrement du probleme ? 

6 

Les acteurs de la gestion des problemes pratiquent-ils des escalades vers la 
gestion des changements afin d’augmenter la priorite de la demande de 
changement correspondant a la resolution de probleme a impact majeur ? 


Definition des procedures 

1 

Existe-t-il une procedure d’escalade permettant au Centre de services de faire 
appel aux experts pour analyse d’un incident majeur (significatif) ou de plusieurs 
incidents recurrents ? 

2 

Existe-t-il une procedure ou un mode operatoire permettant d’enregistrer les 
problemes, de les suivre et de centraliser les analyses jusqu’a leur resolution ? 

3 

Le processus de gestion des problemes est-il cartography ? 

9 

Les activites de recherche des causes structurelles de non-qualite de service, 
d’etude et d’implementation des correctifs de ces causes sont-elles precisement 
attributes a des personnes dans I’organisation ? 

4 

Les roles et responsabilites des differents acteurs de la gestion des problemes 
sont-ils definis et realises en tant que tels ? 

5 

Existe-t-il une procedure ou un outil permettant de correler les incidents afin de 
detecter des incidents recurrents ? 

6 

Existe-t-il une procedure pour affecter des priorites aux problemes par revaluation 
de leur urgence, de leur impact sur la qualite de service ? 

7 

La coordination des experts sur les problemes transversaux est-elle organisee 
selon une procedure definie ? 

8 

Des standards ou d’autres normes de qualite sont-ils definis et appliques a la 
gestion des problemes ? 



Pilotage operationnel 

1 

Les acteurs du processus de gestion des problemes sont-ils responsables de 
I’ensemble du contenu lors de la phase d’enregistrement des problemes ? 

2 

Les solutions proposees pour le traitement d’un probleme font-elles I’objet d'une 
validation ? 

3 

L'investigation, le diagnostic et revaluation des problemes enregistres font-ils I’objet 
d’une mise a jour pour rendre compte de I’avancement de leur resolution ? 

4 

Le responsable des equipes de la gestion des problemes a-t-il dans sa mission 
effectue une revue des problemes enregistres ? 

5 

Les problemes resolus font-ils I’objet d’une mise a jour ? 
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6 

Les demandes de changements sont-elles emises par les acteurs de la gestion des 
problemes suite a leurs analyses ? 

8 

L’organisation utilise-t-elle des outils industriels et appropries a ses besoins pour 
permettre aux acteurs de la gestion des problemes d’atteindre ses objectifs ? 

9 

Existe-t-il une reunion reguliere entre les acteurs de la gestion des problemes et 
d’autres acteurs pouvant etre parties prenantes en fonction des sujets traites ? 

10 

Les gestions de problemes sur les environnements de production de services et sur 
les environnements de developpement de services sont-elles regulierement en 
relation pour la capitalisation des erreurs rencontrees sur les plates-formes de test 
et les bugs de developpement detectes en production ? 

11 

Existe-t-il des rapports standard produits reguliers pour rendre compte des activites 
de la gestion des problemes ? 

12 

Le rapport de la gestion des problemes fait-il etat des activites et des resultats 
d’une gestion proactive des problemes ? 

13 

Le responsable de la gestion des problemes produit-il des rapports sur la 
performance de I’activite a I’intention du management ? 

14 

La gestion des problemes tient-elle la direction informee sur les tendances 
inquietantes ou les risques majeurs de non quality de service ? 


Interrelation processus 

1 

La gestion des configurations est-elle tenue informee par la gestion des problemes 
concernant la qualite des enregistrements de configuration et la decouverte averee 
des elements de configuration juges defaillants ? 

2 

La gestion des problemes et la gestion des changements communiquent-elles 
ensemble de fagon efficace sur les changements a planifier pour la resolution des 
problemes ? 

3 

La gestion des problemes partage-t-elle des informations avec la gestion des 
incidents dans le but de detecter les incidents recurrents presentant des 
symptomes similaires ? 

4 

La gestion des problemes apporte-t-elle son soutien et son conseil au Centre de 
services pour les incidents correspondant a des problemes ? 

5 

La gestion des problemes partage-t-elle la hierarchisation des problemes avec la 
gestion des niveaux de services afin de s'assurer de la coherence entre les 
priorites donnees et I’impact sur la performance des SLA ? 

6 

La gestion des problemes est-elle mise en rapport avec la gestion de la continuity 
des services, en ce qui concerne la documentation et les tests d’actions d’urgence 
en cas de sinistre ? 

7 

La gestion des problemes est-elle mise regulierement en relation avec la gestion de 
la disponibilite pour I’anticipation des problemes et des incidents sur les services 
ainsi que pour son devoir de conseil au sujet de la capacity d’engagement sur de 
futures exigences des clients ? 

8 

La gestion des problemes est-elle alimentee par la gestion de la capacity suite a la 
detection de risques potentiels de non-QoS au regard du planning de capacity, de 
la surveillance de la performance et de la capacity des composants ? 


204 Ameliorer la qualite des services 



Management 

1 

Les acteurs de la gestion des problemes ont-ils ete formes au processus de gestion 
des problemes ? 

2 

Lefficacite et I'efficience du processus de gestion des problemes font-elles I’objet 
de mesure, de suivi et d’ameliorations continues ? 

3 

□replication et le support de la direction sont-ils suffisamment concrets sur I’apport 
de moyens et le pilotage de la capacite a faire des acteurs devant intervenir dans le 
cadre de la gestion des problemes ? 

4 

La direction est-elle tenue informee regulierement sur les problemes recurrents, 
atypiques, complexes, ou majeurs ? 

5 

La gestion des problemes fait-elle appel a la direction en cas de besoin de 
ressources supplementaires (formations, competences de renfort specifiques, 
budget) ? 

6 

Existe-t-il une personne qui porte la responsabilite de la gestion des problemes et le 
management des equipes sur cette activite au sein de la production informatique ? 
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Chapitre 10 

Indicateurs 


Indicateurs d’activite 

Cette partie a pour objectifde presenter Vutilite et des exem- 
ples d’indicateurs de mesure pour I’ensemble des activites du 
processus de gestion des problemes. 

Nous apporterons des reponses a la question suivante : 

Quels indicateurs d’activite mettre en place selon les differen- 
tes activites du processus de gestion des problemes ? 

Les indicateurs d’activite du processus de gestion reactive et proac- 
tive des problemes vont permettre de mesurer les entrees/sorties de 
chaque activite du processus. Les indicateurs d’activites sont des 
comptages. 

Indicateurs d’activite pour la phase identification 
et enregistrement des problemes 

Nombre de problemes ouverts par : 

• declarant d’origine (Centre de services, experts SI Production, 
infogerance, maitrise d’oeuvre, etc.) ; 

• code cause ; 

| • type de symptome ; 

8, • services touches ; 

" • categorie (fonctionnelle, systeme, base de donnees, etc.) ; 
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• domaine metiers (facturation, valorisation) ; 

• environnement (production, plate-forme de test, plate-forme de 
developpement) ; 

• etc. 

Nombre de nouveaux problemes ouverts : 

• depuis moins d’un jour ; 

• depuis 2 a 5 jours. 

Nombre de problemes ouverts selon les types de detection : 

• detection reactive ; 

• detection proactive. 

Indicateurs d’activite pour la phase classement des problemes 

Nombre de problemes ouverts par priorite (PI, P2, P3) ; 

Nombre de problemes ouverts et repartis selon le surcout Sexploita- 
tion evalue : 

• impact de surcout d’exploitation > 3 j/h mois ; 

• 1 j/h mois impact de surcout d’exploitation 3 j/h mois ; 

• impact de surcout d’exploitation 1 j/h mois ; 

• sans impact de surcout d’exploitation ; 

• surcout d’exploitation a determiner. 

Nombre de problemes ouverts et repartis selon le niveau d’impact 
sur la qualite de service : 

• impact QoS fort ; 

• impact QoS moyen ; 

• impact QoS faible ; 

• sans impact QoS. 

Indicateurs d’activite pour la phase investigations et diagnostics 
des problemes 

Nombre de problemes en cours d’investigation par : 

• centre de competence ; 

• code cause ; 
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• type de symptome ; 

• priorites ; 

• services touches ; 

• categorie (fonctionnelle, systeme, base de donnees, etc.) ; 

• domaine metiers (facturation, valorisation) ; 

• environnement (production, plate-forme de test, plate-forme de 
developpement) ; 

• etc. 

Rapport entre le nombre de problemes ouverts et le nombre de 
problemes en cours d’investigation. 

Indicateurs d’activite pour la phase resolution et cldture des 
problemes 

Nombre de problemes resolus et clos par : 

• centre de competences ; 

• code cause ; 

• type de symptome ; 

• priorites ; 

• services touches ; 

• categorie (fonctionnelle, systeme, base de donnees, etc.) ; 

• domaine metiers (facturation, valorisation) ; 

• environnement (production, plate-forme de test, plate-forme de 
developpement) ; 

• etc. 

Rapport entre le nombre de problemes en cours d’investigation et le 
nombre de problemes en cours de resolution par la mise en place 
d’une solution provisoire. 

„ Nombre de demandes de changements emises par centre de compe- 
| tence pour la resolution des problemes. 

| Nombre de problemes dont la non-reproductibilite est mise sous 

^ observation. 
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Indicateurs d’activite pour la phase identification 
et enregistrement des erreurs 

Nombre d’erreurs connues enregistrees dans la base des Erreurs 
connues. 

Nombre de modes operatoires de support a la gestion d’incidents 
enregistres dans la base des Erreurs connues. 

Indicateurs d’activite pour la phase evaluation des erreurs 

Nombre d’erreurs en cours devaluation par : 

• centre de competences ; 

• code cause ; 

• type de symptome ; 

• priorites ; 

• services touches ; 

• categorie (fonctionnelle, systeme, base de donnees, etc.) ; 

• domaine metiers (facturation, valorisation) ; 

• environnement (production, plate-forme de test, plate-forme de 
developpement) ; 

• etc. 

Rapport entre le nombre d’erreurs enregistrees et le nombre d’erreurs 
en cours d’evaluation. 

Nombre d’erreurs dont 1’evaluation a permis de statuer sur la non 
mise en oeuvre d’une resolution. 

Nombre d’erreurs dont la resolution est embarquee dans le version- 
ning (demarche garantissant la stabilite du systeme d’information) 
d’une prochaine mise en production. 

Nombre d’erreurs non reproductibles sur les environnements de test. 

Indicateurs d’activite pour la phase enregistrement 
de la resolution de l’erreur 

Rapport entre le nombre d’erreurs en cours d’evaluation et le nombre s 
d’erreurs dont la resolution est enregistree. 

Nombre de demandes de changement emises pour la resolution des | 


erreurs. 
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Indicateurs d’activite pour la phase cldture des erreurs 
et des problemes associes 

Rapport entre le nombre d’erreurs ouvertes et le nombre d’erreurs 
cloturees. 

Nombre d’erreurs dont la non-reproductibilite est mise sous observa- 
tion. 

Indicateurs de performance 

Cette partie a pour objectif de presenter Vutilite et des exem- 
ples d’indicateurs de performance appeles Key Performance 
Indicators (KPI). 

Nous verrons que les indicateurs de performance du proces- 
sus se distinguent selon 4 types : Relation client, efficacite, 
efficience et flexibility. 

Nous apporterons des reponses a la question suivante : 

Quels indicateurs mettre en place selon le type de perfor- 
mance a suivre ? 

Indicateurs de relation au client 

L’indicateur Relation client du processus gestion des problemes a 
pour objectif de mesurer la perception des utilisateurs et clients de la 
DSI par rapport aux objectifs du processus. 

Le questionnaire ci-contre permet de collecter l’avis des clients avec 
4 choix de reponses possibles : 

• tres insatisfaisante ; 

• insatisfaisante ; 

• satisfaisante ; 

• tres satisfaisante. 

Les questions sont reparties par grands domaines : 

• Quelle est votre appreciation du respect des niveaux de services 
sur votre metier ? 

• Comment jugez-vous le niveau de comprehension de votre metier 
et des enjeux d’affaires de vos interlocuteurs de la DSI ? 

• Comment jugez-vous le pilotage des actions d’amelioration de la 
qualite de service ? 
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• D’une maniere generate, comment appreciez-vous les efforts 
d’amelioration de la qualite de service ? 

• Quelle est votre appreciation de la fiabilite de vos outils 
informatiques ? 

• Comment jugez-vous la proactivite de la DSI ? 

• Que pensez-vous du support et du conseil apportes par la DSI sur 
les pannes informatiques qui interrompent votre activite ? 

• Quelle est votre appreciation concernant la rapidite de diagnostic 
et d’analyse des pannes informatiques que vous avez pu 
rencontrer ? 

• Comment percevez-vous l’efficacite de la capitalisation des 
acteurs de la DSI ? 

• Comment jugez-vous les resultats concernant les actions de 
reduction des temps d’indisponibilite de services ? 

Les questions etant fermees a 4 choix possibles, il est conseille 
d’ajouter au formulaire une rubrique qui permettra de laisser champ 
libre aux messages et aux idees que les clients peuvent apporter sur 
une question comme « Quels axes d’amelioration nous recomman- 
dez-vous ? » 

Indicateurs de mesure de l’efficacite du processus 

Les indicateurs d’effteacite du processus vont etre utiles pour mesurer 
l’atteinte de deux facteurs critiques de succes (Critical Success 
Factor) : 

• ameliorer la qualite de service ; 

• minimiser (impact des incidents et des problemes sur l’entreprise. 
Quelques exemples d’indicateurs de l’efficacite du processus : 

• diminution du nombre d’incidents majeurs ; 

• diminution du taux de repetition des incidents et des problemes ; 

• reduction du nombre de points de qualite de service perdus par 
service ; 

• reduction du nombre de problemes non diagnostiques ; 

• diminution du taux d’incidents non resolus par le support 
niveau 1 en autonome, suite a (application d’un mode operatoire 
disponible dans la base des Erreurs connues ; 
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• diminution du nombre de changements, avec impacts sur la 
qualite de service, emis pour resolution d’un probleme ; 

• diminution du nombre de problemes identifies sur les environne- 
ments de production de services, non reproductibles sur les envi- 
ronnements de developpement de services ; 

• diminution du taux de problemes identifies sur les environne- 
ments de production de services non reproductibles sur les envi- 
ronnements de developpement de services ; 

• reduction du temps de resolution concernant les 20 % de proble- 
mes generant 80 % des incidents a fort impact sur l’entreprise ; 

• reduction du temps moyen de mise en oeuvre de la solution 
provisoire sur les problemes majeurs ; 

• augmentation du taux de changements realises avec succes pour 
correction d’erreurs dans l’infrastructure du SI, en prevention 
d’incidents potentiels ; 

• reduction des pertes de chiffre d’affaires, suite a la resolution des 
problemes. 

Indicateurs de mesure de l’efficience du processus 

Les indicateurs d’efficience du processus vont etre utiles pour piloter 

les couts de la gestion des problemes. 

Quelques exemples d’indicateurs de l’efficience du processus : 

• reduction du temps moyen passe par centre de competences sur 
la gestion des problemes ; 

• reduction de la duree moyenne d’un probleme par type de 
priorite ; 

• reduction du nombre de problemes escalades ; 

• reduction du taux de rejet des problemes dans le cadre du 
processus ; 

• taux de problemes traites en autonome par un fournisseur 
externe. 
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Indicateurs de mesure de la flexibilite du processus 

Les indicateurs de flexibilite du processus doivent vous permettre 
d’evaluer la capacite du processus a fonctionner sur le traitement de 
probleme atypique ou les cas particuliers. 

Un exemple d’indicateur pour piloter la flexibilite du processus est le 
nombre de variantes du processus de gestion des problemes definies 
suite a l’usage du processus generique. 


© 



Chapitre 11 

Pour aller plus loin 


Interactions avec la Gestion des anomalies 

Cette partie a pour objectif de faire etat des interactions 
entre le processus de gestion des problemes sur les environ- 
nements de production de service et sur les environnements 
de developpement de service. 

Nous aborderons les similitudes entre ces deux processus 
jumeaux et done complementaires Vun de Vautre pour 
Vamelioration de la qualite de service. 

Nous apporterons des reponses aux questions suivantes : 
Comment sont geres les problemes d’un environnement a 
Vautre ? 

Comment les processus de gestion des problemes de ces deux 
environnements interagissent-ils ? 

Au sein d’une DSI, la direction des developpements tient la corde 
pour delivrer les services developpes dans les delais impartis selon 
une feuille de route bien souvent tres chargee. Parce que le develop- 
pement du service doit etre de qualite, la direction des tests y 
travaille en synergie avec les equipes projets. Malheureusement, il 
arrive que la non-qualite de service constatee en production soit la 
consequence de non-conformites par rapport aux specifications de 
developpement. 

Il s’agit bien souvent la aussi de deux mondes qui s’opposent : 

• La direction des developpements de service a des projets. Elle est 
necessairement objectivee sur le respect des dates de livraison. 
Son activite est par definition proactive. 
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• La direction de la production de service a des imperatifs d’exploi- 
tation et de maintien des services au niveau de qualite attendu 
par les clients. Son activite a une forte composante reactive, de 
par les activites de soutien quotidien du service. 

Cependant, les producteurs de service qui ne se dotent pas d’un lien 
efficace avec le monde des developpements ne pourront pas faire 
valoir leurs exigences d’exploitabilite de service sur les nouveaux 
projets ou meme beneficier de la connaissance issue des analyses 
effectuees sur les plates-formes de test. 

Pour ameliorer les interactions entre les producteurs de service et les 
developpeurs de service, le processus de gestion des problemes 
s’articule de la meme maniere dans les deux entites. Une relation 
cyclique s’effectue entre ces deux processus symetriques. 


Production des Developpement des 



Figure 12.1 : Cycle de vie des problemes entre les environnements de 
production et de developpement de service 
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Le processus de gestion des problemes, aussi bien reactif que proac- 
tif, est une pierre angulaire entre le monde de la production de 
service et le monde du developpement de service. Ce processus est 
done transversal a ces deux directions et permet d’aligner toutes les 
competences sur la qualite de service. 

Lorsque la non-qualite de service constatee en production est conse- 
cutive a des non conformites par rapport aux specifications de deve- 
loppement, la production devrait ouvrir un probleme et assigner les 
experts de la direction des developpements afin : 

• d’identifier, hierarchiser la correction de ces anomalies selon la 
priorite du probleme qui leur est associe ; 

• de suivre la correction de ces anomalies et done la livraison du 
correctif en coherence avec la priorite du probleme associe ; 

• de capitaliser sur les modes operatoires et les outils de test pour 
eviter la reapparition d’anomalies de meme type sur les environ- 
nements de production des services (non-reproductibilite). 

La gestion des problemes sur les environnements de developpement 
de service comporte les memes activites que celle mise en oeuvre sur 
les environnements de production de service. 

La figure 12.2 illustre les interactions entre la gestion des problemes 
des environnements de production et de developpement concernant 
les anomalies detectees en production : 

L’ouverture des problemes associes a une anomalie sur l’environne- 
ment de production s’effectue dans deux cas de figures generiques : 

• Cas de figure n°l : le probleme est ouvert suite a un incident a 
fort impact sur la qualite de service et dont la cause est due a une 
anomalie. Par extension, il peut s’agir d’un probleme ouvert suite 
a un incident sans solution de contournement ayant donne lieu a 
l’ouverture d’une anomalie. 

• Cas de figure n°2 : le probleme est ouvert suite a la detection 
d’incidents recurrents dont la cause est due a une anomalie. Par 
extension, il peut s’agir d’un probleme ouvert suite a incident 
compense et ayant donne lieu a l’ouverture d’une anomalie. 

| Dans la pratique : 

I • Une anomalie de conformite par rapport aux specifications de 
| developpement, detectee sur l’environnement de production est 


pendant la gestion de 
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Figure 12.2 : Gestion des problemes et am 
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un probleme en production (et dans certains cas une erreur 
connue). 

• Les anomalies de conformite par rapport aux specifications de 
developpement peuvent etre closes a la mise en production de 
leur correctif definitif. Le dossier probleme auquel l’anomalie est 
associee peut ensuite etre definitivement cloture par le Comite de 
Suivi des problemes si les criteres de cloture sont remplis avec 
succes a Tissue de la periode d’observation predefinie. 

• En cas de reproduction d’une anomalie cloturee pendant la 
periode d’observation de la non-reproductibilite, l’anomalie devra 
etre ouverte a nouveau ; elle conservera son anciennete (par 
rapport a sa date initiale de creation). 

• En cas de reproduction d’une anomalie cloturee apres la periode 
d’observation de la non-reproductibilite, Tanomalie et le 
probleme associe devront etre ouverts a nouveau. 

Structuration et partage de l’experience 

Ce chapitre a pour objectif de presenter Vapport du processus 
de gestion des problemes sur les principes et la demarche 
d’enrichissement et de partage de la capitalisation. Dans le 
cadre du processus de gestion des problemes, cette capitali- 
sation est traduite par la mise en place et Ventretien des 
bases de Problemes et d’Erreurs connues. 

Nous exposerons dans ce chapitre la necessite d’une structu- 
ration de ces bases. 

Nous apporterons des reponses aux questions suivantes : 
Comment organiser les bases des Problemes et Erreurs con- 
nues pour une plus grande efficacite de leurs utilisations ? 
Comment normaliser V organisation des donnees ? 

Sur le terrain, les activites reactives et proactives du processus 

permettent d’enrichir la base des Problemes et la base des Erreurs 

Connues qui representent un support considerable pour la gestion 
g des incidents et le Centre de services. 

J- La mise a disposition de la liste des Problemes en cours, des Erreurs 
I et des Erreurs connues aide le Centre de services a communiquer 
| avec le client de fagon pertinente. 
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Tous les conseils, les bonnes pratiques et les modes operatoires 
disponibles et applicables au premier niveau de support de la gestion 
des incidents sont essentiels pour l’amelioration de la qualite de 
service : rappelez-vous que la non-QoS est proportionnelle au degre 
d’impact occasionne sur le service ainsi qu’au delai de resolution des 
incidents sur le service. La rapidite de la resolution des incidents est 
un pilier pour le maintien de la qualite de service. 

Nous le savons, les incidents enregistres par le Centre de services 
sont rarement nouveaux. A l’identique (et a fortiori), les incidents 
traites par les supports de niveaux 2 et 3 sont egalement rarement 
differents les uns des autres. Tout incident, meme original, a de fortes 
chances d’avoir deja ete vecu par les acteurs du support en charge de 
retablir le service. 

La reussite de cette quete de la qualite de service perenne tient 
essentiellement dans la capacite qu’auront les experts de niveaux 2 
et 3 a formaliser leur savoir-faire sous la forme de recettes, afin que 
le Centre de services puisse exploiter a son tour des methodes et une 
pratique cadres par une documentation claire et applicable a leur 
niveau. Le processus de gestion des problemes permet d’assurer le 
partage de connaissance par le biais de la base des Problemes et des 
Erreurs connues dans laquelle est reference l’ensemble des informa- 
tions pouvant servir a la gestion des incidents. 

La responsabilite du processus est de permettre a l’organisation de 
beneficier de l’ensemble de la connaissance technique permettant de 
copier le savoir-faire du meilleur expert. L’idee est simple : l’organisa- 
tion ne doit pas etre dependante de la disponibilite d’une compe- 
tence rare car la qualite de service pourrait en patir un jour ou l’autre. 
Plus le Centre de services a le pouvoir de resoudre les incidents a son 
niveau, plus la qualite de service s’ameliore : le temps d’indisponibilite 
du ou des services pendant l’incident se raccourcit mecaniquement, par 
la reduction des escalades susceptibles d’intervenir pour sa resolution. 
Comment structurer ces informations de sorte que le Centre de servi- 
ces puisse facilement utiliser les informations qui s’y trouvent ? II faut 
surtout se rappeler le contexte d’activite du Centre de services : il est 
au contact du client au quotidien. Pour etre efficace dans le delai de J 
traitement des incidents, de demandes ou de plaintes qui lui sont |- 
remontees, il a besoin de comprendre rapidement ce dont il s’agit | 
avec le minimum d’indices. Puis il a besoin d’etre capable de rappro- | 
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cher ce qui doit etre traite avec le mode operatoire qui permettra de 
faire ce traitement le plus vite possible. 

La capitalisation, au travers des bases de Problemes et Erreurs 
connues, passe done par un besoin de standardiser l’information sur 
les incidents et sur les moyens de resolutions associes. Sans cela, il 
deviendrait rapidement impossible au Centre de services d’utiliser ces 
informations car le temps est compte sur la gestion des incidents. Le 
Centre de services a done besoin de bases des Problemes et d’Erreurs 
Connues homogenes. Il a besoin de comprendre l’information dans 
un temps record, sans etre oblige d’avoir a refaire un nouvel effort 
intellectuel a chaque consultation des donnees contenues dans ces 
bases. Pour arriver a cela, dans le cadre de la gestion des problemes, 
nous observons deux elements fondamentaux : 

• Nous disposons de l’ensemble des informations qui peuvent 
caracteriser les incidents qui se rattachent ou qui pourraient etre 
rattachees a un probleme donne. 

• Nous connaissons les informations qui definissent la solution 
provisoire et definitive d’un probleme donne. Nous pouvons 
done compter sur l’ensemble des informations qui peuvent aider 
dans la strategic de resolution des incidents susceptibles de se 
reproduire et associes aux problemes enregistres. 

Pour structurer la base des Erreurs connues et des Problemes, nous 
allons done standardiser ces deux elements fondamentaux. L’objectif 
global d’une telle demarche vise a normaliser le procede de qualifica- 
tion d’un dysfonctionnement declare au Centre de services. 

La normalisation de ce procede doit donner une connaissance exacte 
du dysfonctionnement, en associant des la prise d’appels les informa- 
tions utiles qui vont caracteriser son identite. L’enjeu est de taille car 
les problemes auront ete hierarchises convenablement (par niveau 
d’impact et d’urgence). Toutes les informations qui permettent de 
rassembler ces deux elements fondamentaux sont precieuses pour 
maintenir la qualite de service, en cas de reproduction ou de repro- 
ductibilite des impacts associes aux causes sous-jacentes (que celles- 
ci soient traitees provisoirement, en cours de traitement ou traitees de 
s fagon incorrecte). 

| L’enjeu est done de disposer, de fagon standard et centralisee, de 
I toutes les reponses qui caracterisent les problemes existants et qui 
| peuvent etre declares a nouveau au Centre de services. 
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Figure 12.3 : Normalisation des incidents 


Normalisation du dysfonctionnement Normalisation de la resolution 

Standard n"1 : la notion de 
« dysfonctionnement standard » caracterisee 
par les pannes susceptibles de survenir sur 
un service donne. 

Standard n'6 : la notion de « localisation 
standard » caracterisee par les ST 
susceptibles d’etre incrimines dans la 
panne occasionnee. 

Standard n"2 : la notion de « groupe 
utilisateur standard » caracterisee par 
I’identite des utilisateurs et I’utilite donnee au 
service dans I’entreprise. 

Standard n'5 : la notion « d’impact 
standard » caracterisee par la gene 
occasionnee chez I’utilisateur et/ou pour 
I’entreprise par rapport a chacun des types 
de pannes survenues sur un service 
donne. 

Standard n"3 : la notion de « duree standard 
de remise en service » caracterisee par la 
duree moyenne de remise en service pour 
chacun des types de pannes survenues sur 
un service donne. 

Standard n‘4 : la notion de « plan standard 
de remise en service » caracterisee par le 
schema d’actions a realiser pour remettre 
en service le plus vite possible. 


Standards n° 1 et 6 , le dysfonctionnement standard doit etre carac- 
terise par les criteres de : 

• qualification « ql » : domaine metier, activite ; 

• qualification « q2 » : application ; 

• qualification « q3 » : dysfonctionnement (indisponibilite/incohe- 
rence/ ralentissement. . .) ; 

• qualification « q4 » : localisation. 

Standards n° 2 et 5 ; la connaissance du groupe utilisateur standard 
doit etre caracterisee par : 1 

• Niveau 1, definition des utilisateurs : §. 

- liste des utilisateurs ; ° 
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• Niveau 2, definition des metiers : 

- metier des utilisateurs concernes ; 

- gene occasionnee sur l’activite des utilisateurs et/ou pour 
l’entreprise (service affecte) ; 

- enjeux des utilisateurs concernes. 

• Niveau 3, definition des applications utilisees : 

- presentation tres succincte de l’application et/ou de Poutil 
utilise(s) ; 

- liste des prerogatives a mettre en place selon une duree 
d’impact specifique ; 

- liste des informations a transmettre selon l’impact decele. 

En complement, cette documentation devrait etre suivie par des 
sessions de presentation/formation a l’intention du Centre de services 
et dispensees par la gestion des problemes. Cela permettrait egale- 
ment d’assurer la mise a jour de cette documentation. 

Ces trois niveaux d’information sont a associer au critere de qualifica- 
tion « q3 » presente dans le standard n°l. 

Standards n° 3 et 4 ; la connaissance de la duree standard de remise 
en service doit etre caracterisee par : 

• Niveau 1, definition des actions a faire (ou a ne pas faire) : 

- mode operatoire de contournement ; 

- aide au diagnostic pour resolution ; 

- consignes sur les messages d’erreurs possibles ; 

- bonnes pratiques. 

• Niveau 2, controle des actions : 

- detail des actions de verification a faire. 

• Niveau 3, duree des actions : 

- delai moyen de remise en service (si un mode operatoire de 
contournement existe) ; 

- information pour escalade de l’equipe gestion des problemes 
sous un delai predefini. 

Ces trois niveaux d’information sont a associer au critere de qualifica- 
tion « q4 » presente dans le standard n l . 

I 

I Attention, la memorisation des solutions est une base vivante. II est 
| important que les experts soient sensibilises et actifs quant a la verifi- 
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cation et l’entretien regulier des informations contenues dans la base 
des Problemes et dans la base des Erreurs connues. Pour entretenir 
ce capital, il faut : 

• Une mise a jour des problemes indexes avec les donnees de 
nouveaux incidents realisables de fagon simple. 

• Un controle regulier et rigoureux permettant de s’assurer de la 
pertinence et de la viabilite de la documentation d’exploitation a 
la lumiere : 

- Des changements de technologie implementes dans le systeme 
d’information. 

- De la veille technologique active, permettant de degager les 
solutions externes disponibles et adequates. 

- Des nouvelles competences internes. 

- Du partage de connaissance entre experts permettant de dega- 
ger le substrat de ce qu’il faut faire avec la connaissance 
mutualisee de plusieurs experts. 

- De la frequence et de la gravite des incidents recurrents. 

- Des pratiques internes a promouvoir. 

• De veritables sessions de partage d’information et de formation 
sur la base des documentations d’exploitation disponibles. Ces 
sessions peuvent permettre de partager des retours d’experience 
avec le Centre de services et la gestion des incidents sur l’utilisa- 
tion des documentations ainsi que de demontrer leur pertinence. 

Le Centre de services doit etre informe et forme pour acceder aux 
donnees contenues dans la base des Problemes ou des Erreurs 
connues le plus vite possible, pour maitriser ces informations et les 
recuperer lors d’exercices d’entrainement et de simulation. Cela va 
permettre au Support de niveau 2 et 3, c’est-a-dire aux acteurs en 
charge de rediger ces documents qui vont enrichir la base des Erreurs 
connues et de s’assurer que le contenu est utile au Centre de services. 


ANNEXE 1 


LlSTE DES INFORMATIONS RELA TIVES A UN PROBLEME 
DANS LA BASE DES PROBLEMES 

Un probleme ouvert et enregistre dans la base des Problemes doit 
comporter un certain nombre d’informations qui vont constituer sa 
carte d’identite. Les informations qu’il faut necessairement avoir trace 
sont les suivantes : 

• l’indice du probleme : numero du probleme ; 

• le statut du probleme ; 

• un libelle court du probleme ; 

• le domaine metier concerne ; 

• la date et l’heure d’ouverture du probleme ; 

• la date et l’heure du dernier incident rattache au probleme ouvert ; 

• 1’evaluation de la reproductibilite selon 3 niveaux : 
faible/moyenne/forte ; 

• le nom de l’operateur qui a ouvert le probleme ; 

• le nombre d’incidents rattaches au dossier Problemes ; 

• la priorite du probleme ; 

• la classification du probleme ; 

I • l’environnement (production, test, autres) ; 

8. • l’application concernee ; 

" • l’impact QoS (exemple : impact QoS Fort/Moyen/Faible/Sans) ; 
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• le code cause du probleme ; 

l’impact d’exploitation (evalue en Jour/Homme) ; 

• le detail de la description du probleme ; 

le detail des impacts de services lies au probleme ; 

• le groupe en charge : nom du groupe support auquel est affecte 
le probleme. 


ANNEXE 2 


Communication si r la mise en place du processus 

DE GESTION DES PROBLEMES 

Le plan de communication est essentiel pour promouvoir le change- 
ment. La trame du plan de communication devrait a minima inclure 
les 10 points suivants : 

• Faire un seminaire pour favoriser l’eclosion d’idees (brainstor- 
ming) sur le projet : 

- Definir un pilote, son perimetre, ses acteurs ; 

- Definir une date de demarrage. 

• Organiser des plans de formation a la gestion des problemes pour 
les acteurs du pilote. 

• Annoncer de fagon formalisee et officielle la creation des nouvel- 
les activites en lien avec la mise en place du processus de gestion 
des problemes. 

• Organiser un lancement officiel (kick-off) en presentant le pilote 
organise pour la mise en oeuvre du processus de gestion des 
problemes : 

- Soigner l’accueil des participants ; 

- Inviter le management des acteurs du pilote et le sponsor du 
processus ; 

- Inviter les clients du perimetre explore par le pilote. 

• Publier a occurrences regulieres le tableau de bord d’activite du 
processus ainsi que les deux ou trois indicateurs cles de succes. 
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• Communiquer sur les bonnes nouvelles vers la direction et 
remonter en toute transparence les difficultes rencontrees durant 
la phase pilote. 

• Faire un bilan de la phase pilote avec l’ensemble des acteurs 
ayant participe au pilote. Presenter : 

- les benefices du pilote ; 

- les difficultes rencontrees ; 

- les moyens mis en ceuvre pour traiter les difficultes ; 

- l’ebauche du plan d’action et les questions a se poser pour 
aller plus loin. 

• Faire un seminaire pour a nouveau confronter les idees (brains- 
tormer) sur la suite du deployment avec un groupe d’acteurs 
representatifs de l’ensemble de la population concernee et le 
management de chaque direction contributrice. 

• Organiser un demarrage officiel (kick-off) pour presenter la strate- 
gic de deploiement du processus aux acteurs. Etre precis sur des 
questions existentielles que peuvent se poser les acteurs : 

- Qui a le droit d’ouvrir des problemes ? 

- Qui pilote les problemes ? 

- Comment les hierarchiser par priorite ? 

- Comment est-on informe sur le probleme ? 

- Quelle instance de pilotage ? 

- Quel outil ? 

• Organiser des plans de formation cibles pour les acteurs du 
processus, des forums d’echanges, etc. 


ANNEXE 3 


Repartition des roles et responsabilites de l’equipe 

EN CHARGE DU CHANGEMENT 

Pour conduire le changement, nous vous proposons ci-apres un 
modele detaille de repartition des roles et responsabilites. 


Role 

Mission 


Donne la direction sur le projet de transformation. A le pouvoir de decision sur la 
structuration de I'organisation et des metiers. 

§ 

Ses responsabilites 

1 

• II definit la strategie sur un plan global. 

(/) 

• II oriente et arbitre sur les ameliorations structurantes au sein de la DSI. 


• II decide et s’assure de I’orientation a donner au projet en fonction de la strategie 
SI et affaires de I’entreprise. 


Le comite de direction intervient en tant que comite executif dirige par le sponsor. 

c 

Ses responsabilites 

.2 

• II gere les conflits de priorites sur les questions structurantes d’organisation au 

£ 

sein de la DSI. 


• II decide d’axes d’ameliorations a apporter en fonction des enjeux et de la 

a> 

strategie d’entreprise. 

'0 

• II defend des ameliorations prioritaires pour la bonne conduite du plan de 

'I 

transformation. 

o 

• II valide les resultats de chaque etape de la definition du processus en s’assurant 


de la coherence avec la strategie definie du plan de transformation. 

• II valide la strategie d'accompagnement du changement pour chacune des 
etapes devolution du processus. 
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• II encourage la propagation de bonnes pratiques entre les services et entre les 
structures. 


II defend la voie de I’industrialisation, de la centralisation et du partage de 

2 

I’information contenus dans les outils en support du processus. 

w 

II intervient pour arbitrer sur les difficultes de mise en oeuvre du plan de 


transformation afin d’attenuer toute resistance au changement. 

.2 

• II s’assure de la maturity des ameliorations engagees au sein de I’organisation de 

8 

fagon transversale. 


II valide la communication institutionnelle sur le projet de transformation. 

Q) 

II a le pouvoir de faire appel a des experts internes ou externes pour I’etude d’une 

'O 

difficulty particuliere rencontrees dans le cadre de la mise en oeuvre du plan de 

'1 

transformation. 

o 

• II a le droit et le pouvoir de commander des audits. 


• II donne son accord pour I'investissement de moyens complementaires pour 
I’atteinte de I’objectif. 


• II examine et valide le budget global du projet. 


Le comite Projet est le maTtre d’ceuvre du projet. II est dirige par le chef de projet, 
et est responsable de tracer la ligne directrice definie par le comite de direction. 


Ses responsabilites 


• II anime des groupes de travail transversaux et assure la coordination des 


differents acteurs. 

.2, 

• II apporte le cadre methodologique et operationnel pour I’accomplissement du 


plan de transformation. 


• II apporte une vision et un support sur les principes, approches, normes et 

1 

bonnes pratiques de la qualite. 

O 

• II intervient a I’aide de points de controle pour s’assurer de I’avancement des 
travaux et communiquer vers le sponsor et le comite de direction. 

• II apporte son support dans la realisation des livrables. 

• II est I’eclaireur d’une demarche de cooperation des competences entre les 
services, et entre les structures (le facilitateur). 

• II intervient en tant qu’acteur a part entiere sur les sujets sensibles afin de faciliter 
I’operabilite des etapes cles du plan de transformation. 


Le directeur de projet est le responsable des jalons sur I’ensemble du projet de 
transformation pour le compte du sponsor. II est le garant de la bonne tenue du 
comite Projet. 

Conseil : rattacher physiquement et operationnellement le directeur de projet au sein 
meme du service vise en tout premier lieu par le changement. 

■a 

| 

Ses responsabilites 

3 

! 

• II realise le rapport aupres du sponsor du projet et anime un plan de 
communication global. 

• II est le garant de la coherence globale entre tous les processus qui interagissent 
avec le processus faisant I’objet du plan de transformation (avec I’equipe projet). 

• II pilote le projet par les notions basiques de cout, delai, qualite et risque. 

5 

• II encadre I’equipe projet qui participe au comite projet. 

• II assiste le sponsor pour I’arbitrage des decisions locales en coherence avec le 
plan global de transformation. 

• II dynamise I’accompagnement du changement. 

• II intervient en support du proprietaire pour la traduction operationnelle des 
decisions prises dans le cadre du comite de direction. 
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2 

• II organise des seminaires pour promouvoir et veiller a la participation des 
acteurs concernes par le changement en collaboration avec le gestionnaire du 
processus. 

• II tient a jour et communique les indicateurs de pilotage du projet global. 

• II redige les notes de cadrage selon la definition du plan de marche decide par le 
comite de direction. 

■S 

• II soutient toutes les demandes de moyens supplementaires aupres du sponsor 

1- 

du projet et du comite de direction. 

0 

• II consolide le chiffrage du budget dedie au pilotage operationnel du projet de 


transformation et en est le gerant. 


• II participe au chiffrage du retour sur investissement des ameliorations a engager 


sur le processus. 


Le proprietaire du processus est le garant de la satisfaction des clients sur son 
processus et, a ce titre, il est responsable des resultats du processus. II est 
rattache fonctionnellement au sponsor. 

m 

Ses responsabilites 

m '® 

• II definit les grandes lignes et fixe les objectifs sur son processus. 

• II assure une vision de bout en bout de son processus. 

8 P 

• II identifie et met en oeuvre les moyens necessaires a I’atteinte de I’objectif de son 


processus en coherence avec le plan de transformation globale. 

2-g 

• II arbitre les ameliorations a apporter au processus conjointement avec le 

3 c 

sponsor. 

.2 

• II est le sponsor local du processus. 

a. £ 

o gj 

• II defend les ameliorations de son processus. 

£ 0 

• II delegue au gestionnaire du processus la mise en place des chantiers 

TJ 

d’amelioration et s’assure de la coherence avec le plan de transformation 
globale. 

• II assiste le gestionnaire du processus dans I’accompagnement au changement. 


• II a le pouvoir d’intervenir afin de traiter les conflits en lien a la resistance au 
changement sur son processus. 


C’est le garant de la mise en oeuvre et de la performance du processus. II depend 
du proprietaire de processus. 

II est responsable par delegation de la mise en oeuvre des ameliorations arbitrees 
par le proprietaire dans son domaine. Assurez-vous de lui donner les moyens de 

W 0 

cette gestion. 

II 

Ses responsabilites 

O 2 

• II definit le processus de gestion des problemes en prenant en compte les 

t* 

meilleures pratiques issues d’lTIL. 

2« 

• II assure la mise en oeuvre du processus et I’accompagnement au changement 

1 = 

des structures concernees. 


• II contribue a la definition des objectifs. 

.2 m 

II est responsable de la gestion des moyens du processus : 

2 Si 

• II definit les roles et responsabilites. 

° -S 

• II anime les acteurs parties prenantes du processus. 

• II intervient dans I’allocation des ressources necessaires. 

• II anime le comite de pilotage du processus gestion des problemes. 

• II met en oeuvre la definition des indicateurs de pilotage du processus. 

• II specifie et met en place les outils du processus. 
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S 8 
°! 


• II est responsable de la performance : 

• II pilote la performance du processus en veillant a I’adequation des moyens 
necessaires a I’atteinte des objectifs. 

• II definit et pilote les indicateurs de mesure de la performance du processus. 

• II assure I’autorite d’audit aupres des structures agissant dans le cadre du 
processus. 

• II anime I’amelioration continue du processus et accompagne le changement au 
sein de la DSI. 


3 | 


Loperateur du processus est responsable d’activites definies dans le cadre du 
processus. Ces activites font I’objet d’un rapport au gestionnaire de processus. 


Ses responsabilites 

II est responsable de la tragabilite des problemes (le contenant et le contenu) : 

• II s’assure de la completude et de la centralisation de I’ensemble des 
informations pour chaque dossier probleme de son portefeuille. 

• II s’assure de la gestion des statuts des dossiers problemes de son portefeuille. 


II 

If 

s 1 


<5 

8 8 


II est responsable de la gestion des moyens d’expertise : 

• II s’assure de la mobilisation des experts necessaires sur I’ensemble des 
dossiers Problemes de son portefeuille. 

• II organise et anime les groupes d’intervention d’experts. 

• II apporte des conseils aux equipes de gestion des incidents sur les bonnes 
pratiques issues de I’expertise effectuee sur la gestion de son portefeuille de 
problemes. 

• II pilote les activites operationnelles d’identification, d’enregistrement, de 
hierarchisation, d’investigation et de mise en place de solutions sur les 
problemes de son portefeuille (proactive et reactive). 

• II intervient en escalade et arbitrage dans I’allocation des ressources 
necessaires. 

• II pilote le plan de resolution des Erreurs connues sur son portefeuille. 

• II est garant de la bonne coordination avec les activites operationnelles de la 
gestion des changements, des incidents, et des autres processus en support aux 
services. 


II est responsable de la performance de son activite. II pilote la performance des 

activites mises en oeuvre dans le cadre de la gestion de son portefeuille a I’aide 

des indicateurs definis par le proprietaire et le gestionnaire du processus. 

II est responsable du rapport sur son activite : 

• II assure le rapport sur I’avancement de son portefeuille de dossiers problemes 
aupres des acteurs operationnels et du management. 

• II assure I’instruction, le suivi et la communication sur les alertes remontees par 
les acteurs en charge du maintien de la qualite de service. 

• II anime des presentations et remonte des alertes et/ou besoins dans le cadre 
des instances de pilotage a haut niveau de la DSI. 

• II rend compte de I’avancement, des alertes et des besoins d’escalade dans le 
cadre du comite de Suivi des problemes. 


u 

1 


...A.. 


ANNEXE 4 


ETAPES DETAILLEES DU DEPLOYMENT DU PROCESSUS 

Etape 1 : Analyser l’existant 

1. Se faire (re)confirmer par le sponsor et le proprietaire du proces- 
sus, le degre et la logique de changement recherches. S’agit-il 
d’une logique d’amelioration ou de rupture ? 

2. Enrichir son portefeuille d’information sur le projet a mener avec 
des actions de collecte de donnees par l’intermediaire de deux 
demarches : 

• Demarche participative animee par le chef de projet : 

- Identifier les difficultes qui preoccupent les participants aux 
groupes de travail (normalement, chacun exprime le sujet qui 
le preoccupe). 

- Obtenir des informations factuelles et chiffrees. 

- Permettre a tous de prendre connaissance de l’ensemble des 
informations disponibles, et surtout de prendre la parole. 

- Faire la synthese des difficultes de fonctionnement sur le 
processus en obtenant des participants aux groupes de travail 
une formulation commune des difficultes a resoudre. 

• Demarche individuelle du chef de projet : 

- Realiser des observations sur le terrain (analyses qualitatives et 
quantitatives) et mener des entretiens aupres des utilisateurs 
identifies comme detenteurs de l’information. 
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3. Mettre en forme l’ensemble des informations recueillies pour vali- 
dation par le sponsor, le proprietaire du processus, les inter- 
view's et les participants aux groupes de travail : 

• Cartographier le processus « boite fermee » (processus dans sa vue 
d’ensemble avec l’objectif et l’enjeu du processus) ; 

• Cartographier le processus « boite ouverte » (description des acti- 
vites du processus avec les acteurs et les outils utilises pour les 
differents scenario ; 

• Decrire des roles et responsabilites sur les activates detaillees en 
coherence avec le processus « boite ouverte » ; 

• Auditer les outils utilises et faire un bilan. 

Le tableau suivant est un exemple de canevas simplifie pour repre- 
senter un bilan synthetique des outils. 


Nom de I’outil 

Description de I’outil 


Progiciel ou developpement maison ? 


Qui effectue le support ? 


Qui le parametre ? 


Qui I’administre ? 


Interface avec d’autres outils (si oui, lesquels ?) 


Outil de workflow (logiciel libre-open source) 



• Faire le bilan des indicateurs d’activite existants et verifier. 

• Faire le bilan des indicateurs d’efficacite, d’efficience, de flexibilite 
du processus existants. 


Veillez a considerer I’importance de cette etape et a impliquer I’energie 
necessaire pour faire le bon diagnostic sur I’existant du processus. II faut la 
aussi raisonner en gestion des problemes : si le probleme du processus et/ou 
de I'organisation etudies est mal pose, cela risque de fausser le diagnostic et j 

peut provoquer I’echec de la conduite du changement sur les solutions 1 

d’amelioration identifies. I « 
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4. Confronter l’analyse de Pexistant a l’aide d’interview ciblee pour 
prendre des notes complementaires selon les quatre angles de 
lecture suivants : 

• le management ; 

• la structure ; 

• les systemes ; 

• la culture. 

II s’agit des leviers de l’accompagnement du changement. 

Etape 2 : Critiquer l’existant 

1 . Faire ressortir les points forts et les points de dysfonctionnement : 

• issus de la collecte au travers d’entretien et d’interviews avec les 
acteurs du processus ; 

• issus de la collecte au travers de groupes de travail ayant permis a 
plusieurs groupes d’acteurs du processus d’exprimer leurs ressen- 
tis. 

2. Faire l’analyse critique de l’existant : 

• Mettre en exergue et formaliser les points forts et les dysfonction- 
nements et/ou difficultes du processus en identifiant leurs causes 
et leurs effets. 

3. Consolider l’analyse critique de l’existant : 

• Formaliser l’analyse en classant par themes. 

• Faire verifier l’analyse critique consolidee, par les acteurs inter- 
viewes et les differents groupes de travail sollicites. 

• Faire approuver l’analyse critique consolidee et verifier par les 
acteurs du processus, par le sponsor et le proprietaire du proces- 
sus. 

4. Communiquer les resultats au management : 

• Presenter Paralyse critique dans le cadre du comite de direction. 

Etape 3 : Realiser le diagnostic 

1. Rechercher toutes les causes possibles donnant lieu au dysfonc- 
tionnement et/ou aux insatisfactions sur le processus avec une 
serie de questions ciblees : 

• Qui est a l’origine de tel ou tel dysfonctionnement ? 


234 Ameliorer la qualite des services 


Quand tel ou tel dysfonctionnement apparait-il ? 

Ou observe-t-on tel ou tel type de dysfonctionnement, dans 
quelle structure ? 

Quelles sont les sources du dysfonctionnement (faits annoncia- 
teurs, signaux) ? 

Pourquoi tel ou tel dysfonctionnement existe-t-il ? 

Quel est l’impact de tel ou tel dysfonctionnement ? 

Sur quelles structures organisationnelles l’impact est-il le plus 
fort? 

Sur quelles structures organisationnelles repose le processus ? 
Quelle est la raison d’etre, la vocation de l’organisation en place 
(de chaque structure dans l’organisation) ? 

A quels objectifs l’organisation en place repond-elle ? 

A quels objectifs Porganisation devrait-elle repondre afin : 

- d’etre en meilleure adequation avec son environnement ? 

- de disposer d’objectifs plus clairs ? 

- de favoriser une plus grande autonomie et responsabilisation 
des individus ?... 

L’organisation subit-elle des changements ? Des pressions (Envi- 
ronnement/Technologie/Structure. . .) ? 

Quelles ont ete les dernieres reorganisations ? 

Quels problemes ces reorganisations ont-elles regies ? 

Quel est le mode de fonctionnement relationnel entre les 
structures ? 

Quelles sont les interdependances de flux et d’echanges entre les 
acteurs ? 

Quel est le niveau de qualite des relations entre les acteurs ? 
Comment s’explique la presence ou l’absence de conflits ? 

Quelles sont les incidences des conflits ? 

Qui possede les competences pour regler les conflits ? 

Quels mecanismes sont en place pour regler les conflits ? 

Sur quels facteurs peut-on jouer pour favoriser l’excellence au 
sein de la structure ? 
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- Quels sont les facteurs de motivation des acteurs ? 

- Existe-t-il un systeme de recompenses, si oui lequel ? 

• Sur quels facteurs peut-on jouer pour favoriser l’excellence au 
sein de la structure ? 

• Dispose-t-on des moyens adequats pour assurer le management 
de la structure ? 

• Le style de leadership convient-il aux objectifs poursuivis ? 

• Quel est le style de management en vigueur ? 

• Comment s’organise la coherence entre les objectifs, la structure, 
les relations et le management ? 

• Quels sont les mecanismes facilitants ? 

• Quels sont les freins ? 

2. Formaliser les causes pouvant donner lieu au dysfonctionnement 
identifie dans l’existant. 

NB : pensez a illustrer a chaque fois que c’est possible par des mesu- 

res quantitatives. 

3. Classer les causes en fonction de leur importance. 

4. Selectionner les types de causes qui vont etre identifiees comme 
les principales causes de la survenance des dysfonctionnements 
les plus importants sur le processus. 

Etape 4 : Elaborer et choisir les solutions 

1 . Faire ressortir l’elaboration des solutions d’ameliorations : 

• Issus de la collecte au travers d’entretiens et d’interviews avec les 
acteurs du processus. 

• Issus de la collecte au travers de groupes de travail ; pour cette 
action, utilisez au maximum la creativite et la force de proposition 
du groupe et des acteurs interviewed. 

2. Rechercher les supports documentaires en termes de meilleures 
pratiques existantes (en interne et en externe) sur le processus 
etudie. 


| Ne pas oublier que les meilleures pratiques ne sont pas uniquement en 
'S provenance d’lTIL. Les meilleures pratiques internes peuvent constituer un 
P excellent point d’ancrage pour le developpement. 

o 
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3. Formaliser l’objectif de chaque solution/amelioration. Pour 
chaque axe d’amelioration, il faut definir : 

• la cible ; 

• les benefices attendus ; 

• les indicateurs de suivi ; 

• le plan de mise en oeuvre. 


Verifier que ces 4 points soient dans la lignee de I’objectif global promu par le 
sponsor et le proprietaire du processus et faire valider les plus et les moins de 
chacun des axes d’ameliorations par les acteurs interviewes. 


4. Classer et evaluer les axes d’ameliorations. Le classement des 
ameliorations s’effectue par la selection de criteres de decision 
qui doivent caracteriser la difficulte de mise en oeuvre (cout, 
delai) et le gain (qualite). Une amelioration se doit d’etre evaluee. 
C’est la base qui va permettre d’identifier son retour sur investis- 
sement. 

Etape 5 : Mettre en oeuvre 

1. Elaborer le plan d’action. Il s’agit d’un veritable programme de 
campagne dans lequel des responsabilites doivent etre 
distributes : 

• Nommer un responsable pour chaque different theme d’actions. 

• Planifier l’ensemble des actions. 

Note : n’oubliez pas d’inclure dans le plan d’actions toutes les prero- 
gatives necessaires pour le pilotage de l’industrialisation des outils de 

support ou de mesure de la performance du processus (indicateurs). 

2. Tester la solution en organisant une phase pilote : 

• Choisir un pilote. 

• Le choix du pilote est primordial et un choix pertinent va faciliter 

d’autant plus la phase de deployment. Ne choisissez pas la faci- 
lity. Il vaut mieux faire un pilote difficile et en tirer des enseigne- | 
ments pertinents pour le deploiement, que de faire un pilote tres J> 
aise (du au choix effectue), et se rendre compte de toutes les | 
difficultes et contraintes lors du deploiement. ° 
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• Mettre en place et suivre le fonctionnement de la solution/axe 
d’amelioration sur le perimetre du pilote et pendant la periode 
determinee. 

• Faire un bilan incluant les avantages constates, les difficultes 
rencontrees, les actions de corrections a mettre en oeuvre pour 
moduler. 

3. Apporter les corrections necessaires sur le perimetre du pilote. 
Cela permet notamment de verifier la pertinence de ces correc- 
tions et d’enregistrer leur existence : 

• Mettre a jour la cartographic boite blanche du processus. 

• Mettre a jour la description des roles et responsabilites inherents 
au processus concerne ainsi que pour les processus affectes. 

4. Deployer la solution/axe d’amelioration, la mettre en place et 
suivre son exploitation. 

Etape 6 : Suivre et ajuster 

1. Surveiller les conditions de mise en place de la solution. II s’agit 
de garder une ecoute forte du terrain (la sonde) afin de collecter 
toutes les remarques pouvant etre remontees par les acteurs qui 
utilisent la solution mise en oeuvre et/ou l’axe d’amelioration. 

2. Mesurer de fagon continue les resultats obtenus afin de : 

• Cadrer les resultats obtenus avec les objectifs initiaux poursuivis 
par l’etude. 

• Evaluer avec le proprietaire du processus les ameliorations obte- 
nues. 

• Mesurer le differentiel entre le prevu et le realise. 

• Communiquer sur les resultats. 

3. Apporter des corrections et des modifications afin de : 

• Prendre en compte si necessaire les remarques des acteurs du 
processus pilote. 

• Repondre a des ajustements d’organisation mis en oeuvre par la 
Direction. 

4. Mettre en place les modifications et la surveillance des conditions 
de mise en place de la solution (cf. supra). 
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Ecueils a eviter lors de la mise en place d’une gestion 

DES PROBLEMES 

L’historique des incidents n’est ni maintenu ni centralise. 

La fonction de gestionnaire des problemes n’est pas clairement defi- 
nie dans l’organisation. Elle est partagee entre le Centre de services, 
les experts, les maftrises d’oeuvre, et ce en fonction des situations. 

Les incidents significatifs (ou majeurs) sont pilotes par le Centre de 
services. 

Une instance permettant de developper la fiabilite des services est 
planifiee en recurrence avec la participation de la direction, seule- 
ment cette instance n’est pas associee a un processus clair et defini. 

II n’existe pas de procedure pour analyser les incidents afin de detec- 
ter les incidents recurrents et d’identifier les problemes associes. 

II existe plusieurs bases d’Incidents differentes et cloisonnees entre 
elles. 

La saisie des incidents dans la base ne respecte pas le meme modele 
de donnees rendant complexe tout effort de correlation sur ces inci- 
dents. 

Les incidents sont exclusivement decrits de fagon technique ne 
| permettant pas de rattacher les symptomes a un service affecte. 

8. Les experts ne disposent pas d’acces a la base des Incidents. 

" La base Incidents n’est pas maintenue a jour. 
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Chaque structure organisationnelle de la DSI a mis en oeuvre son 
propre processus de gestion des problemes. 

Les regies d’identification d’un probleme sont differentes d’une struc- 
ture organisationnelle a une autre, au sein meme de la DSI. 

Les problemes ne sont pas enregistres. Les seules informations persis- 
tantes sur les problemes traites sont contenues dans les mails ou dans 
des documents references dans differents endroits. 

Le Centre de services ne remonte pas d’alertes vers les experts en cas 
de detection d’un incident repetitif. 

II n’existe pas de base des Erreurs connues. 

II n’existe pas de base des Problemes. 

Les Problemes sont ouverts via un outil de workflow qui ne trouve 
pas d’interface avec la base des Incidents. 

Le personnel de la gestion des problemes est sollicite au-dela du 
raisonnable par la gestion des incidents. 

Les Problemes ouverts sont hierarchises selon une regie non decrite 
et non partagee par chaque acteur. 

Le Centre de services ne connait pas, n’utilise pas ou n’a pas acces a 
la base des Erreurs connues. 


Les Problemes ouverts sont hierarchises selon une regie non decrite 
et non partagee par chaque acteur. 

Les maitrises d’oeuvre ne sont pas associees au processus de gestion 
des problemes de la production et vice versa. 


La base des Problemes sur les environnements de developpement 
des services et celle sur les environnements de production des servi- 
ces ne communiquent pas entre elles. 

Les maitrises d’oeuvre ne sont pas associees au processus de gestion 
des problemes de la production et vice versa. 

Les problemes declares sont rejetes sans explication. 


Les analyses menees sur les incidents ne sont pas tracees dans la 
base Incidents, obligeant les experts a jouer les archeologues sur ce 
qui a ete realise pour resoudre les incidents. 


Les problemes declares sont rejetes sans explication. 

II n’existe aucune mesure de l’activite de gestion des problemes. 
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Le cout de la gestion des problemes est inconnu et les gains ne sont 
pas systematiquement evalues. 

Le Centre de services n’est pas tenu informe de l’avancement du trai- 
tement des Problemes ou verts. 

Les experts qui interviennent dans la gestion des problemes commu- 
niquent regulierement en direct avec les clients sur l’avancement des 
dossiers traites. 

La gestion des problemes execute des modifications sur les environ- 
nements de production qui ne sont pas controlees par la gestion des 
changements. 

La gestion des problemes n’apporte pas de soutien a la gestion des 
incidents pour la resolution d’incidents complexes. 

Tous les incidents ne sont pas traces. 

Les codes causes des incidents ne sont pas renseignes de fagon perti- 
nente ou un code cause « valise » rassemble a lui seul plus de 50 % 
des incidents. 

Les bugs detectes pendant les phases de tests ne figurent pas dans 
l’historique d’une base de Problemes. 

Les indicateurs d’activite sur la gestion des incidents ne sont pas 
produits ou sont systematiquement contestes, a cause de la multipli- 
cite des rapports existants. 

Les problemes sont tous traites en meme temps sans distinction des 
efforts de soutien a fournir en fonction des priorites. 

La gestion des incidents majeurs n’est pas decrite et s’improvise en 
fonction de la gravite de l’impact. 

Absence d’un bon processus de controle des incidents (historique 
incomplet des incidents). 

Echec a relier les incidents avec les problemes pour analyser preven- 
tivement les problemes. 

Manque d’engagement et d’implication de la hierarchie. 

Impossibility aux equipes intervenant dans le controle des incidents 
de degager du temps pour trouver des reponses structurelles aux 
problemes. 

| Acceptation de demandes de sources multiples par les experts. 

I Signalement multiple d’un incident avec des interpretations differen- 

'S tes. 
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Difficulty a maintenir et a entretenir les bases de Problemes et 
d’Erreurs connues. 

Incapacity a determiner l’impact des incidents et des problemes sur 
les activites de l’entreprise. 

Les incidents et les problemes critiques ne sont pas identifies avec la 
bonne priority. 

Le partage des roles et responsabilites n’est pas clair. 

Le referentiel des codes causes n’est pas partage ou est inexistant. 
Une concurrence est en place entre les equipes de la gestion des 
incidents et les equipes de la gestion des problemes. 

La capacity de travail du personnel de la gestion des problemes n’a 
pas ete etudiee et dimensionnee en consequence. 

Tous les problemes ne sont pas traces. 


© 
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Amelioration continue 

Cle de voute des meilleures pratiques en termes de gestion des services des 
technologies informatiques, il s’agit du principe de la roue de Deming 
(cycle PDCA pour Plan, Do, Check, Act, soit planifier, mettre en oeuvre, 
controler, corriger). Toutes les composantes des activites de l’entreprise sont 
continuellement remises en question afin d’identifier les ameliorations 
potentielles au niveau de sa relation avec ses clients, de sa flexibility, de son 
efficacite et de son efficience. 

Anomalie 

Condition qui occasionne qu’une unite fonctionnelle n’execute pas sa fonc- 
tion telle que specifiee dans un contrat. Une anomalie designe alors le non- 
respect d’une exigence prevue et/ou specifiee par ce contrat. 

Audit 

Processus d’inspection, de correction et de controle. 

Capacite 

Puissance, performance, contenu et rendement maximum d’un composant 
du systeme d’information. 

Capitalisation 

Connaissances transmises pour produire toute information qui fait l’objet 
d’une documentation formalisee et enregistree dans un referentiel pour la 
mise a disposition d’un ensemble d’acteurs. 

Cause initiale 

C’est la raison de l’apparition d’un incident. Elle est identifiee par la gestion 
d’incidents. Il s’agit alors de la raison apparente. Pour fixer les idees : son 
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identification correspond aux reponses que l’on peut obtenir en se posant 
une a deux fois la question du « pourquoi » par rapport aux symptomes qui 
caracterisent l’incident. 

Cause sous-jacente 

C’est la raison originelle de l’apparition d’un incident. Elle est identifiee par 
la gestion des problemes. 11 s’agit alors de la raison cachee. Son identifica- 
tion correspond aux reponses que l’on peut obtenir en se posant cinq a six 
fois la question du « pourquoi » par rapport aux symptomes qui caracterisent 
l’incident. 

Centre d’appels (ou call center) 

Interface de communication entre l’entreprise et le client. La vocation du 
centre d’appels est de receptionner un grand nombre d’appels et de traiter 
toutes les transactions telephoniques. C’est un dispositif frequemment utilise 
dans les services de televente. 

Centre d’assistance (ou help desk) 

Interface de communication entre la technologie informatique et ses utilisa- 
teurs. 11 s’agit du point de contact unique (ou guichet unique) de la direc- 
tion informatique. Ce dispositif s’appuie sur le processus de gestion des 
incidents et de gestion des demandes, et a pour objectif de traiter les appels 
dans les delais les plus courts possible en s’assurant qu’aucun appel n’est 
perdu, oublie ou ignore. 

Centre de services (ou service desk) 

Le Centre de services offre une approche globale et permet a l’ensemble des 
processus de l’entreprise d’etre inclus dans l’infrastructure de la gestion des 
services. 

En plus d’etre connecte avec les incidents, les interrogations et les doutes 
des utilisateurs, le Centre de services est en interface avec d’autres activites 
emanant d’autres processus comme la gestion des changements, la gestion 
des niveaux de services, la gestion des configurations, la gestion de la 
disponibilite, la gestion des problemes, la gestion financiere des services 
informatiques et la gestion de la continuite. 

Changement (ou change) 

Tout ajout, modification ou suppression d’un element de configuration du 
systeme d’information. Tout composant du systeme (y compris sa documen- 
tation) est a considerer comme element de configuration du systeme d’infor- 
mation. 

Changement urgent (ou Emergency Change) 

Changement dont l’organisation de la planification et la mise en application I 
sont prevues pour s’effectuer dans un delai court afin de sauvegarder la “ 
qualite de service contre un risque inacceptable de degradation ou d’inter- g 
ruption de service. | 
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Cl (Configuration Item) 

Element de l’infrastructure du systeme d’information, necessaire pour four- 
nir un service unique et identifiable, modifiable et gerable, documents 
(hardware, software, procedures, organisation, service Level Agreement, 
etc.) 

Client 

Celui qui paye pour obtenir la fourniture d’un service informatique. 

11 est destinataire d’un service. 11 est le signataire du contrat de service avec 
la direction informatique. 

Dans certains cas particulars, « Client » = * Utilisateur ». 

CMDB sigle de Configuration Management Data Base 

Base de donnees des configurations de l’infrastructure du systeme d’infor- 
mation. Cette base de donnees contient l’ensemble des informations concer- 
nant les elements de configuration, leurs relations et leur historique. 

Contexte 

Description du constat des symptomes caracterisant un incident. 

Crise 

Impact dont l’etendue a provoque un sinistre dans l’entreprise, c’est-a-dire 
une mise en danger imminente de son image de marque et/ou de son chif- 
fre d’affaires. 

Criticite 

Indice permettant de caracteriser et hierarchiser le degre d’importance mate- 
rialisant l’enjeu de l’exigence du client concernant la qualite du service 
souhaite et du delai de carence autorise pour la poursuite des activites 
metiers. Ce degre d’importance permet d’attribuer un score aux consequences 
possibles si l’exigence n’est pas satisfaite. 

Ce score depend de deux parametres : la frequence (correspondant a la 
periode ou l’exigence doit etre satisfaite) et l’impact (correspondant a la 
non-qualite de service induite par le fait du non respect de l’exigence). On 
peut distinguer 3 scores de criticite : 

Cl : elevee ; C2 : moyenne ; C3 : faible. 

Direction des systemes d’information (DSI) 

La direction des systemes d’information a pour responsabilite de dispenser le 
service informatique de l’entreprise et a pour role de trouver les reponses infor- 
matiques aux besoins strategiques de l’entreprise. 

| Erreur connue 

S' Le probleme devient une erreur connue lorsque la cause du (ou des) inci- 
I" dent(s) est trouvee et que la solution palliative est identifiee, mais que la 
^ solution definitive n’est pas encore implementee. 
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Fiabilite 

Pourcentage de temps pendant lequel le systeme fonctionne sans erreur. 
Dans la pratique, la fiabilite est exprimee par le temps moyen entre deux 
incidents (Mean Time Between System Interruptions). 

Concernant la restitution de donnees, la fiabilite inclut l’integrite, la comple- 
tude, la fraicheur et la lisibilite des informations. 

Gestion des niveaux de services 

11 s’agit du processus qui definit, documente, negocie, gere et suit revolu- 
tion des niveaux de qualite de service convenus en accord avec le client 
dans le cadre du contrat de service. 

Gestion de la capacite 

11 s’agit du processus qui garantit la capacite et la performance des services 
delivres par la Direction des systeme d’information pour le bon client, au 
bon moment et au meilleur prix, dans le respect des exigences et des enga- 
gements de services contractes dans le cadre du contrat de service. 

Impact 

11 s’agit de la consequence negative subie par l’entreprise et induite par 
l’apparition d’un incident ou d’un probleme. 11 est courant de la categoriser 
selon les themes suivants : Client final, ■< Business » (chiffre d’affaires/image), 
Client interne. 

Incident 

Evenement ne faisant pas partie de l’exploitation standard d’un service et 
qui cause, ou peut causer, une interruption ou une diminution de la qualite 
de service. 

Note : les demandes de service sont prises en compte par le processus de 
gestion d’incident. 

Incident dit « standard » 

II s’agit d’un incident dont les actions de resolution sont documentees et 
gerees dans le cadre d’une exploitation recurrente. A fortiori, ces incidents 
sont repertories par des Problemes ouverts et font l’objet d’un enregistre- 
ment dans la base des Erreurs connues. 

Incident dit « non standard » ou incident complexe 

II s’agit d’un incident dont les actions de resolution necessitent une analyse 
prealable non documentee (ou partiellement). L’intervention de supports 
specialises, acteurs du processus de gestion des problemes est done indi- 
quee en soutien de celle de la gestion d’incidents. Ces supports intervien- 
nent alors en renfort, dans le cadre du processus de gestion d’incidents. 



Glossaire 247 


Incident majeur 

Incident dont l’impact est crucial pour l’entreprise. Les incidents dont le 
delai de traitement a depasse de fa^on extreme le delai contractuel de reta- 
blissement de service convenu devraient etre consideres comme incidents 
majeurs. 

Indicateur cle de performance (KPI : Key Performance Indicator) 

11 s’agit d’une mesure quantitative ou qualitative qui permet a une prestation 
d’etre evaluee sur des criteres objectifs definis au prealable et en coherence 
avec l’objectif de l’activite couverte par un processus donne. On distingue 
4 types d’indicateurs de performance : 

• Les indicateurs de relation Client qui mesurent l’alignement des activites 
du processus par rapport aux attentes du client. 

• Les indicateurs d’efficacite qui mesurent l’atteinte de l’objectif. 

• Les indicateurs d’efficience qui mesurent la reduction du cout dans le 
cadre de l’atteinte de l’objectif. 

• Les indicateurs de flexibilite qui mesurent la capacite du processus a 
s’adapter aux cas particuliers. 

Indicateur d’activite 

II s’agit d’une mesure quantitative des livrables en entrees/sorties de chaque 
activite d’un processus donne. 

Mettre en procedure 

Action consistant a definir, ecrire et referencer les procedures d’une activite. 
Palliatif (solution palliative) 

Un type de solution permettant de contourner l’impact subi. 

Dans le cadre du processus GDI (gestion des incidents) : il s’agit d’un mode 
operatoire permettant de retablir le service au plus vite (selon l’engagement 
de service signe). 

Dans le cadre du processus GDP (gestion des problemes) : il s’agit d’un 
mode operatoire permettant d’eviter la reproductibilite des incidents ratta- 
ches a un probleme donne. 

Synonymes : solution palliative = solution provisoire = solution de contour- 
nement. 

Priorite 

Indice permettant d’identifier l’ordre selon lequel un incident ou un 
probleme doit etre traite et resolu. La priorite P est fonction de l’impact I et 
| de l’urgence U : P = f (I, U). 

§ La priorite doit permettre d’arbitrer les dossiers a traiter en cas de conflit lie 
| a la capacite a faire. On peut distinguer 3 types de priorite : 
s 

° PI : forte ; P2 : moyenne ; P3 : faible. 
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Probleme 

Un probleme est la cause inconnue d’un incident significatif ou de plusieurs 
incidents presentant les memes symptomes. 

Production 

Organisation en charge d’assurer et de maintenir la fourniture des services 
attendus par les clients et utilisateurs au quotidien, de garantir l’utilisation 
effkace et efficiente des ressources, de contribuer a la preparation des 
evolutions technologiques, de s’assurer de la security de l’information. 

Qualite de Service (QoS ; Quality of Service) 

C’est « 1‘aptitude d’un produit ou d’un service a satisfaire, au moindre cout et 
dans les moindres delais les besoins des utilisateurs. » [ISO 9000 1982] 

C’est « l’ensemble des proprietes et caracteristiques d’un produit ou d’un 
service qui lui conferent l’aptitude a satisfaire des besoins exprimes ou 
implicites. » [ISO 9000 1987] 

C’est « l’ensemble des caracteristiques d’une entite qui lui confere l’aptitude 
a satisfaire des besoins exprimes et implicites. » [ISO 9000 1994] 

C’est « l’aptitude d’un ensemble de caracteristiques intrinseques a satisfaire 
des exigences. » [ISO 9000 2000] 

La qualite de service est l’aptitude a satisfaire des besoins et des exigences 
de fourniture de service selon des caracteristiques definies de qualite qui 
sont les suivantes : 

• debit ; 

• temps de reponse (disponibilite) ; 

• accessibility ; 

• disponibilite ; 

• performance ; 

• capacite. 

Retablissement de service 

Retour a la normale du fonctionnement du service. Le service est considere 
en etat de fonctionnement normal lorsque son fonctionnement correspond 
aux niveaux de services definis dans le contrat de service (SLA). 

Service 

Un service est un element materiel ou immateriel source de satisfaction par 
rapport a une exigence formelle ou implicite de celui qui l’utilise et le 
pergoit. Ces elements materiels ou immateriels sont decomposables, trans- | 
posables et ferment un ensemble unique. ,§» 

Le service cree la valeur pour celui qui produit et suscite la demande pour g 
celui qui consomme. “ 
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Service « IT » (IT : Information Technology) 

11 s’agit d’un ensemble integre de composants informatiques lies entre eux 
et permettant le fonctionnement d’un ou plusieurs processus d’affaires. Le 
service est done un element de configuration, composable en plusieurs 
autres elements. 11 est neanmoins pergu de fafon unique, coherente et inde- 
pendante par l’utilisateur. 

SLA (Service Level Agreement) 

11 s’agit d’un terme anglo-saxon pour definir le contrat de service. Ce contrat 
est un accord ecrit entre un fournisseur de service et un ou plusieurs clients. 
11 formalise les conditions de fourniture du service et les niveaux de qualite 
de service devant etre delivres. 

Solution definitive 

Solution issue d’une etude devaluation (gain/cout), perenne dans le temps, 
et permettant d’empecher la reproductibilite des incidents rattaches a un 
probleme donne et done de clore le probleme. 

Support de niveau 1 (SN1) 

Niveau de support en charge de la realisation des actions documentees et 
correspondant a un standard d’actions d’exploitation recurrente. 

Support de Niveau 2 (SN2) 

Niveau de support en charge d’apporter une analyse sur le fonctionnement 
de Sexploitation et capable de documenter les actions d’analyse dans le but 
de les inclure dans Sexploitation recurrente. 

Support de Niveau 3 (SN3) 

Expert sur les produits exploites et capable d’inventer des solutions pour la 
perennite du produit dans le cadre de son exploitation recurrente. 

Symptome 

Element visible qui se manifeste lors d’un incident et qui peut aider a sa 
qualification. 


Utilisateur 

Personne de l’entreprise qui utilise le service de fafort quotidienne. 




